Re: remove more archiving overhead - Mailing list pgsql-hackers

From Noah Misch
Subject Re: remove more archiving overhead
Date
Msg-id 20220919143923.GA1706070@rfd.leadboat.com
Whole thread Raw
In response to Re: remove more archiving overhead  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: remove more archiving overhead
Re: remove more archiving overhead
List pgsql-hackers
On Mon, Sep 19, 2022 at 06:08:29AM -0400, Peter Eisentraut wrote:
> On 18.09.22 09:13, Noah Misch wrote:
> >>>This documentation change only covers archive_library.  How are users of
> >>>archive_command supposed to handle this?
> >>
> >>I believe users of archive_command need to do something similar to what is
> >>described here.  However, it might be more reasonable to expect
> >>archive_command users to simply return false when there is a pre-existing
> >>file, as the deleted text notes.  IIRC that is why I added that sentence
> >>originally.
> >
> >What makes the answer for archive_command diverge from the answer for
> >archive_library?
> 
> I suspect what we are really trying to say here is
> 
> ===
> Archiving setups (using either archive_command or archive_library) should be
> prepared for the rare case that an identical archive file is being archived
> a second time.  In such a case, they should compare that the source and the
> target file are identical and proceed without error if so.
> 
> In some cases, it is difficult or impossible to configure archive_command or
> archive_library to do this.  In such cases, the archiving command or library
> should error like in the case for any pre-existing target file, and
> operators need to be prepared to resolve such cases manually.
> ===
> 
> Is that correct?

I wanted it to stop saying anything like the second paragraph, hence commit
d263ced.  Implementing a proper archiving setup is not especially difficult,
and inviting the operator to work around a wrong implementation invites
damaging mistakes under time pressure.



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: confirmed_flush_lsn shows LSN of the data that has not yet been received by the logical subscriber.
Next
From: Larry Rosenman
Date:
Subject: Ubuntu 16.04: Xenial: Why was it removed from the apt repo?