Date: Mon, 19 Sep 2022 07:39:23 -0700
From: Noah Misch <noah@leadboat.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	David Steele <david@pgmasters.net>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>, robertmhaas@gmail.com,
	masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org
Subject: Re: remove more archiving overhead
Message-ID: <20220919143923.GA1706070@rfd.leadboat.com>
References: <20220708.105652.1551158050191356887.horikyota.ntt@gmail.com>
 <44dbf5e4-8eec-da56-daba-755128b3723e@pgmasters.net>
 <20220708165450.GA2356733@nathanxps13>
 <20220731065156.GA3694276@rfd.leadboat.com>
 <20220802050219.GA475090@nathanxps13>
 <20220803071617.GA3817792@rfd.leadboat.com>
 <ebb0f19f-5452-678c-0d19-1b8b260fd331@enterprisedb.com>
 <20220917215427.GB3189289@nathanxps13>
 <20220918071312.GB1658466@rfd.leadboat.com>
 <7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220919143923.GA1706070%40rfd.leadboat.com>
Precedence: bulk

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.