Re: fdatasync(2) on macOS
От | Tom Lane |
---|---|
Тема | Re: fdatasync(2) on macOS |
Дата | |
Msg-id | 289866.1610942929@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fdatasync(2) on macOS (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: fdatasync(2) on macOS
|
Список | pgsql-hackers |
Thomas Munro <thomas.munro@gmail.com> writes: > On Sat, Jan 16, 2021 at 6:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I have a vague recollection that we discussed changing the default >> wal_sync_method for Darwin years ago, but I don't recall why we >> didn't pull the trigger. These results certainly suggest that >> we oughta. > No strong preference here, at least without more information. It's > unsettling that two of our wal_sync_methods are based on half-released > phantom operating system features, but there doesn't seem to be much > we can do about that other than try to understand what they do. I see > that the idea of defaulting to fsync_writethrough was discussed a > decade ago and rejected[1]. > [1] https://www.postgresql.org/message-id/flat/AANLkTik261QWc9kGv6acZz2h9ZrQy9rKQC8ow5U1tAaM%40mail.gmail.com Ah, thanks for doing the archaeology on that. Re-reading that old thread, it seems like the two big arguments against making it safe-by-default were (1) other platforms weren't safe-by-default either. Perhaps the state of the art is better now, though? (2) we don't want to force exceedingly-expensive defaults on people who may be uninterested in reliable storage. That seemed like a shaky argument then and it still does now. Still, I see the point that suddenly degrading performance by orders of magnitude would be a PR disaster. regards, tom lane
В списке pgsql-hackers по дате отправления: