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.