Horton

Re: Loaded footgun open_datasync on Windows

Jeff Janes <jeff.janes@gmail.com>

View thread View on postgr.es
From: Jeff Janes <jeff.janes@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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-23T17:05:04Z
Lists: pgsql-hackers 
On Fri, Sep 14, 2018 at 3:32 AM Michael Paquier <michael@paquier.xyz> wrote:

> On Fri, Sep 14, 2018 at 08:43:18AM +0200, Laurenz Albe wrote:
>
> > If it turns out not to break anything, would you consider backpatching?
> > On the one hand it fixes a bug, on the other hand it affects all
> > frontend executables...
>
> Yeah, for this reason I would not do a backpatch.  I have a very hard
> time to believe that any frontend tools on Windows developed by anybody
> rely on files to be opened only by a single process, still if they do
> they would be surprised to see a change of behavior after a minor
> update in case they rely on the concurrency limitations.
>

Reviving an old thread here.

Could it be back-patched in some pg_test_fsync specific variant?  I
don't think we should just ignore the fact that pg_test_fsync on Windows is
unfit for its intended purpose on 4 still-supported versions.


> > I wonder why nobody noticed the problem in pg_test_fsync earlier.
> > Is it that people running Windows care less if their storage is
> > reliable?
>
> likely so.
>

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.

 Cheers,

Jeff

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