On Sat, Jan 16, 2021 at 6:55 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > So it's not a no-op, but on the other hand it's not succeeding in getting > bits down to the platter. I'm not inclined to dike it out, but it does > seem problematic that we're defaulting to open_datasync, which is also > not getting bits down to the platter.
Hmm, OK, from these times it does appear that O_SYNC and O_DSYNC actually do something then. It's baffling that they are undocumented. It might be possible to use dtrace on a SIP-disabled Mac to trace the IOs with this script, to see if the B_FUA flag is being set, which might make open_datasync better than fdatasync (if it's being sent and not ignored), but again, who knows?!: https://github.com/apple/darwin-xnu/blob/master/bsd/dev/dtrace/scripts/io.d > 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]. I'm not entirely sure how it manages to be so slow. It looks like the reliability section of our manual could use a spring clean[2]. It's still talking about IDE and platters, instead of modern stuff like NVMe, cloud/network storage and FUA flags. [1] https://www.postgresql.org/message-id/flat/AANLkTik261QWc9kGv6acZz2h9ZrQy9rKQC8ow5U1tAaM%40mail.gmail.com [2] https://www.postgresql.org/docs/13/wal-reliability.html
