Horton

Re: Loaded footgun open_datasync on Windows

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Noah Misch <noah@leadboat.com>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-27T04:04:45Z
Lists: pgsql-hackers 
On Thu, Jul 23, 2020 at 01:05:04PM -0400, Jeff Janes wrote:
> I have noticed this before, but since it wasn't a production machine I just
> shrugged it off as being a hazard of using consumer-grade stuff; it didn't
> seem to be worth investigating further.

The most direct and non-invasive way to address this problem in
back-branches would be to copy the non-concurrent logic in
src/port/open.c directly into pg_test_fsync.c.  We have done that in
the past such things for example with restricted tokens on Windows for
pg_upgrade, see fa1e5afa but that was much more important.  I am not
sure that if it is worth the time spent here though, as it took
roughly 10 years to notice the problem (and I don't really count the
time where the tool was under src/tools/ but this did not build the
tool on Windows).
--
Michael

Commits

  1. Allow concurrent-safe open() and fopen() in frontend code for Windows

  2. Fix inclusions of c.h from .h files.

  3. Allow borland compiles.

  4. Corrects issues recently posted by Dann Corbit, allowing libpq/psql to