Re: remove more archiving overhead

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>, Nathan Bossart <nathandbossart@gmail.com>
Cc: David Steele <david@pgmasters.net>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, robertmhaas@gmail.com, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org
Date: 2022-09-19T10:08:29Z
Lists: 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?



Commits

  1. Be more prescriptive in new doc about re-archiving of same WAL file.

  2. doc: Add note about re-archiving of same WAL files in docs.

  3. Reduce overhead of renaming archive status files.