On 09.11.21 21:20, Tom Lane wrote:
Why is this different from the half-dozen
other fsync-error cases in the same file? Why, if fsync failure
here is so catastrophic, is it okay to just return a normal failure
code when tar_close doesn't even get to this point because of some
earlier error? At the very least it seems like it'd be preferable
to do the exit(1) at the caller level.
The addition of the exit(1) seems to have been intentional in
1e2fddfa3, so cc'ing Peter for comment.
That commit addressed the behavior of fsync() failure in pg_receivewal
and pg_recvlogical, which are long-running daemon processes, so this
change was analogous to the server-side changes at the time. I don't
know what the behavior of fsync() failure in pg_basebackup should be, so
calls that are only reachable from pg_basebackup are currently being
handled differently.
