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
-
Be more prescriptive in new doc about re-archiving of same WAL file.
- d263ced225bf 16.0 landed
-
doc: Add note about re-archiving of same WAL files in docs.
- 3cabe45a819f 16.0 landed
-
Reduce overhead of renaming archive status files.
- 756e221db610 16.0 landed