Michael Paquier <michael@paquier.xyz> writes:
> Taking the issues with fsync() aside, which could be improved as a
> separate patch, is there anything I can do for this thread? The error
> handling problems in walmethods.c introduced by the integration of LZ4
> are on me, so I'd like to fix it. 0002 depends on some parts of 0001,
> as well for walmethods.c and the new error code paths. And I have
> been through this code quite a lot recently.
I feel like doing an immediate exit() for these errors and not other
ones is a pretty terrible idea, mainly because it doesn't account for
the question of what to do with a failure that prevents us from getting
to the fsync() call in the first place. So I'd like to see a better
design rather than more quick hacking. I confess I don't have a clear
idea of what "a better design" would look like.
However, that's largely orthogonal to any of the things my proposed
patches are trying to fix. If you want to review the patches without
considering the fsync-error-handling problem, that'd be great.
regards, tom lane
