Re: Volatile write caches on macOS and Windows, redux
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Volatile write caches on macOS and Windows, redux |
Дата | |
Msg-id | CAGECzQTyUztx0UtwsRh=z4fTMGxgGd5Zo5++kYbCg5FtHE59ew@mail.gmail.com обсуждение исходный текст |
Ответ на | Volatile write caches on macOS and Windows, redux (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Volatile write caches on macOS and Windows, redux
|
Список | pgsql-hackers |
On Tue, 18 Jul 2023 at 05:29, Thomas Munro <thomas.munro@gmail.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.
В списке pgsql-hackers по дате отправления: