12 ms·
The error semantics of fsync are very important here and this can get messy, for example see https://danluu.com/fsyncgate/ https://danluu.com/fsyncgate/
by evanelias 2y ago
The error semantics of fsync are very important here and this can get messy, for example see https://danluu.com/fsyncgate/ https://danluu.com/fsyncgate/
- genewitch 2y agoSo uh... I read a third of that, knowing roughly how the rest will go, based only on the context of the thread. However in the back of my mind I know Dan Luu is preserving it for a reason. And I don't know if that's explained later, or whatever; what I do know is Dan Luu has pointed on awe that most fs don't error correctly on write failures - as an example. As in, that isn't even implemented in some fs drivers. So the very idea that somehow Postgres can do direct IO and it magically gets better - to me that's the joke Dan Luu sees. Maybe. That Craig person, the OP in the thread. Imagine doing all that work, having other people say, hey, that's an issue; and then all the people saying "so what" or "nothing can be done" Amazing. I'll have to read the rest a bit later.
- anarazel 2y ago> That Craig person, the OP in the thread. Imagine doing all that work, having other people say, hey, that's an issue; and then all the people saying "so what" or "nothing can be done" For context - Craig's opinion won out, and what he was suggesting (crash-restart and perform recovery) is what postgres has been doing for many years (with an option to revert back to retrying, but I haven't seen anybody toggle that).