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
