Re: Deficient error handling in pg_dump and pg_basebackup

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Deficient error handling in pg_dump and pg_basebackup
Date: 2021-11-17 02:44:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-11-17 02:47:06 Re: pg_get_publication_tables() output duplicate relid
Previous Message Michael Paquier 2021-11-17 02:31:16 Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display