From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Noah Misch <noah(at)leadboat(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Loaded footgun open_datasync on Windows |
Date: | 2020-07-23 17:05:04 |
Message-ID: | CAMkU=1xiBJxRVw=KLSA-eJ_4-s_acqBu056aQTG_t0YZxnEpkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 14, 2018 at 3:32 AM Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-07-23 17:05:32 | Re: 'with' regression tests fails rarely (and spuriously) |
Previous Message | Tom Lane | 2020-07-23 16:57:34 | Making CASE error handling less surprising |