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 1264128B-5757-4A56-974E-45447FC09433@amazon.com
Whole thread Raw
In response to Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
Responses Re: archive status ".ready" files may be created too early  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Attached is a new version of the patch with all feedback addressed.

On 8/16/21, 5:09 PM, "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org> wrote:
> The reason for the latter is that I suspect the segment boundary map
> will also have a use to fix the streaming replication issue I mentioned
> earlier in the thread.  This also makes me think that we'll want the wal
> record *start* address to be in the hash table too, not just its *end*
> address.  So we'll use the start-1 as position to send, rather than the
> end-of-segment when GetFlushRecPtr() returns that.

I've been thinking about the next steps for this one, too.  ISTM we'll
need to basically assume that the flush pointer jumps along record
boundaries except for the cross-segment records.  I don't know if that
is the safest assumption, but I think the alternative involves
recording every record boundary in the map.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: return correct error code from pgtls_init
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side