On Fri, Sep 14, 2018 at 3:32 AM Michael Paquier <mich...@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
