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

From Peter Eisentraut
Subject Re: remove more archiving overhead
Date
Msg-id 7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com
Whole thread Raw
In response to Re: remove more archiving overhead  (Noah Misch <noah@leadboat.com>)
Responses Re: remove more archiving overhead
Re: remove more archiving overhead
List pgsql-hackers
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?



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [RFC] building postgres with meson - v13
Next
From: Zhang Mingli
Date:
Subject: Free list same_input_transnos in preprocess_aggref