From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Volatile write caches on macOS and Windows, redux |
Date: | 2024-05-25 11:01:44 |
Message-ID: | CAGECzQTyUztx0UtwsRh=z4fTMGxgGd5Zo5++kYbCg5FtHE59ew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 18 Jul 2023 at 05:29, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> It's possible that fcntl(F_FULLFSYNC) might fail with ENOSUPP or other
> errors in obscure cases (eg unusual file systems). In that case, you
> could manually lower fsync to just "on" and do your own research on
> whether power loss can toast your database, but that doesn't seem like
> a reason for us not to ship good solid defaults for typical users.
Is this the only reason why you're suggesting adding fsync=full,
instead of simply always setting F_FULLFSYNC when fsync=true on MacOS.
If so, I'm not sure we really gain anything by this tri-state. I think
people either care about data loss on power loss, or they don't. I
doubt many people want his third intermediate option, which afaict
basically means lose data on powerloss less often than fsync=false but
still lose data most of the time.
If you're going to keep this tri-state for MacOS, then it still seems
nicer to me to "fix" fsync=true on MacOS and introduce a fsync=partial
or something. Then defaults are the same across platforms and anyone
setting fsync=yes currently in their postgresql.conf would get the
fixed behaviour on upgrade.
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2024-05-25 12:00:00 | Re: Improving tracking/processing of buildfarm test failures |
Previous Message | Dave Cramer | 2024-05-25 10:53:32 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |