Horton

Re: Deficient error handling in pg_dump and pg_basebackup

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2021-11-17T02:44:19Z
Lists: pgsql-hackers 
On Wed, Nov 10, 2021 at 02:03:11PM +0900, Michael Paquier wrote:
>> but this code seems about as fishy and ill-thought-out as anything
>> else I've touched here.  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?
> 
> Hmm, I don't think that's fine.  There is an extra one in tar_finish()
> that would report a failure, but not exit() immediately.  All the
> callers of the sync callback in receivelog.c exit() on sight, but I am
> wondering if it would not be saner to just exit() from walmethods.c
> each time we see a failure with a fsync().

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.
--
Michael

Commits

  1. Clean up error handling in pg_basebackup's walmethods.c.

  2. Handle close() failures more robustly in pg_dump and pg_basebackup.

  3. Add support for LZ4 compression in pg_receivewal