Horton

Re: Deficient error handling in pg_dump and pg_basebackup

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2021-11-17T03:26:11Z
Lists: pgsql-hackers 
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

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