Re: remove more archiving overhead

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: David Steele <david@pgmasters.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-07T18:19:56Z
Lists: pgsql-hackers
On Thu, Jul 07, 2022 at 02:07:26PM -0400, David Steele wrote:
> On 7/7/22 12:18, Nathan Bossart wrote:
>> On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote:
>> 
>> > There are plenty of ways that already-archived WAL might get archived again
>> > and this is just one of them.
>> 
>> What are some of the others?  I was aware of the case that was fixed in
>> ff9f111, where we might try to re-archive a file with different contents,
>> but I'm curious what other ways you've seen this happen.
> 
> On the PG side, crashes and (IIRC) immediate shutdown.
> 
> In general, any failure in the archiver itself. Storage, memory, network,
> etc. There are plenty of ways that the file might make it to storage but
> postgres never gets notified, so it will retry.
> 
> Any archiver that is not tolerant of this fact is not going to be very
> useful and this patch only makes it slightly more true.

Ah, got it, makes sense.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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.