Re: remove more archiving overhead

On 9/19/22 07:39, Noah Misch wrote:
> 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.

I would also not want to state that duplicate WAL is rare. In practice 
it is pretty common when things are going wrong. Also, implying it is 
rare might lead a user to decide they don't need to worry about it.

Regards,
-David