Hi, On 2018-12-12 10:49:59 +0900, Robert Haas wrote: > Just thinking about this a bit, the problem with truncating first and > then writing the WAL record is that if the WAL record never makes it > to disk, any physical standbys will end up out of sync with the > master, leading to disaster. But the problem with writing the WAL > record first is that the actual operation might fail, and then > standbys will end up out of sync with the master, leading to disaster. > The obvious way to finesse that latter problem is just PANIC if > ftruncate() fails -- then we'll crash restart and retry, and if we > still can't do it, well, the DBA will have to fix that before the > system can come on line. I'm not sure that's really all that bad -- > if we can't truncate, we're kinda hosed. How, other than a > permissions problem, does that even happen?
I think it's correct to panic in that situation. As you say it's really unlikely for that to happen in normal circumstances (as long as we handle obvious stuff like EINTR) - and added complexity to avoid it seems very unlikely to be tested. Greetings, Andres Freund
