Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-09-18T02:42:27Z
Lists: pgsql-hackers
Attachments
- win32-open-mode-v1.patch (text/x-diff) patch v1
On Tue, Sep 18, 2018 at 09:11:43AM +0900, Michael Paquier wrote: > What I think I broke is that CreateFile ignores what _fmode uses, which > has caused the breakage, while calling directly open() or fopen() does > the work. There are also other things assuming that binary mode is > used, you can grep for "setmode" and see how miscinit.c or pg_basebackup > do the job. I have been playing with this stuff, and hacked the attached. Now, while TAP tests of initdb and pgbench are happy (I can actually see the past failure as well), pg_dump complains at authentication time when using plain-text mode when using databases with all ASCII characters. That's not something I expected first, but _get_fmode also influences operations like pipe(), which is something that pg_dump uses, and setmode is enforced to binary mode only when adapted. I am getting to wonder if what's present on HEAD represents actually the best deal we could get. Attached is the patch I used for reference. Thoughts? -- Michael
Commits
-
Enforce translation mode for Windows frontends to text with open/fopen
- 40cfe86068f4 12.0 landed
-
Fix pgbench lexer's "continuation" rule to cope with Windows newlines.
- db37ab2c60b8 12.0 landed
- d45f157e8b07 11.0 landed
- 3ea7e015f37a 10.6 landed
-
Allow concurrent-safe open() and fopen() in frontend code for Windows
- 0ba06e0bfb8c 12.0 cited