From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Date: | 2018-09-17 23:38:24 |
Message-ID: | 11148.1537227504@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
So we seem to be out of the woods in terms of 0ba06e0bf breaking the
regression tests, but I'm not very happy about the whole thing, because
that patch wasn't supposed to change the behavior of open/fopen in any
way other than allowing concurrent file access. Obviously, it did.
After looking at src/port/open.c a bit, it seems like the problem is
that our fopen() requires a nonstandard "t" option to select text mode.
I'd always supposed that you got binary mode with "b" and text mode
otherwise; is there some third possibility on Windows?
Anyway, I'm inclined to propose that we ought to do something like
the attached in HEAD and v11 in order to reduce the risk that there
are other unexpected behavioral changes. This should also let us
revert 0ba06e0bf's change in initdb.c.
I wonder whether pgwin32_open() also ought to enforce that either
O_BINARY or O_TEXT mode gets selected.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
force-either-binary-or-text-open-mode.patch | text/x-diff | 921 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-18 00:11:43 | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Previous Message | Tom Lane | 2018-09-17 22:44:24 | pgsql: Stamp 11beta4. |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-18 00:11:43 | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Previous Message | Thomas Munro | 2018-09-17 23:35:25 | Re: infinite loop in parallel hash joins / DSA / get_best_segment |