Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi

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

In response to

Responses

Browse pgsql-committers by date

  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.

Browse pgsql-hackers by date

  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