Horton

Re: remove more archiving overhead

David Steele <david@pgmasters.net>

View thread View on postgr.es
From: David Steele <david@pgmasters.net>
To: Nathan Bossart <nathandbossart@gmail.com>
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:07:26Z
Lists: pgsql-hackers 
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.

Regards,
-David

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.