On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote: > Craig Ringer <craig@2ndquadrant.com> writes: >> TL;DR: Pg should PANIC on fsync() EIO return. > > Surely you jest.
Any callers of pg_fsync in the backend code are careful enough to check the returned status, sometimes doing retries like in mdsync, so what is proposed here would be a regression.
I covered this in my original post.
Yes, we check the return value. But what do we do about it? For fsyncs of heap files, we ERROR, aborting the checkpoint. We'll retry the checkpoint later, which will retry the fsync(). **Which will now appear to succeed** because the kernel forgot that it lost our writes after telling us the first time. So we do check the error code, which returns success, and we complete the checkpoint and move on.
But we only retried the fsync, not the writes before the fsync.
So we lost data. Or rather, failed to detect that the kernel did so, so our checkpoint was bad and could not be completed.
The problem is that we keep retrying checkpoints *without* repeating the writes leading up to the checkpoint, and retrying fsync.
I don't pretend the kernel behaviour is sane, but we'd better deal with it anyway.
