Message-ID: <02051aee-2ba1-3dd0-e162-8b2e8db79022@pgmasters.net>
Date: Mon, 19 Sep 2022 07:56:35 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Subject: Re: remove more archiving overhead
To: Noah Misch <noah@leadboat.com>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>, robertmhaas@gmail.com,
 masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org
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>
 <20220919143923.GA1706070@rfd.leadboat.com>
Content-Language: en-US
From: David Steele <david@pgmasters.net>
In-Reply-To: <20220919143923.GA1706070@rfd.leadboat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/02051aee-2ba1-3dd0-e162-8b2e8db79022%40pgmasters.net>
Precedence: bulk


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