Re: archive status ".ready" files may be created too early - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: archive status ".ready" files may be created too early
Date
Msg-id EBD2D598-B3B9-4923-A1B8-76A4AEC631B6@amazon.com
Whole thread Raw
In response to Re: archive status ".ready" files may be created too early  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: archive status ".ready" files may be created too early  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 7/27/21, 6:05 PM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote:
> On 2021-Feb-19, Bossart, Nathan wrote:
>
>> 0002 adds logic for persisting the last notified segment through
>> crashes.  This is needed because a poorly-timed crash could otherwise
>> cause us to skip marking segments as ready-for-archival altogether.
>> This file is only used for primary servers, as there exists a separate
>> code path for marking segments as ready-for-archive for standbys.
>
> I'm not sure I understand what's the reason not to store this value in
> pg_control; I feel like I'm missing something.  Can you please explain?

Thanks for taking a look.

The only reason I can think of is that it could make back-patching
difficult.  I don't mind working on a version of the patch that uses
pg_control.  Back-patching this fix might be a stretch, anyway.

> There were some comments earlier in the thread about the maximum size of
> a record.  As I recall, you can have records of arbitrary size if you
> have COMMIT with a large number of relation invalidation messages being
> included in the xlog record, or a large number of XIDs of
> subtransactions in the transaction.  Spanning several segments is
> possible, AFAIU.

This is my understanding, too.

Nathan


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Replace l337sp34k in comments.
Next
From: Andres Freund
Date:
Subject: Re: Autovacuum on partitioned table (autoanalyze)