Re: Loaded footgun open_datasync on Windows
| От | Jeff Janes |
|---|---|
| Тема | Re: Loaded footgun open_datasync on Windows |
| Дата | |
| Msg-id | CAMkU=1xiBJxRVw=KLSA-eJ_4-s_acqBu056aQTG_t0YZxnEpkg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Loaded footgun open_datasync on Windows (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Loaded footgun open_datasync on Windows
|
| Список | 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
В списке pgsql-hackers по дате отправления: