At Sat, 12 Mar 2022 14:33:32 -0800, Nathan Bossart <nathandbossart@gmail.com> wrote in
> On Tue, Mar 08, 2022 at 06:01:23PM -0800, Andres Freund wrote:
> > To me it's architecturally the completely wrong direction. We should move in
> > the *other* direction, i.e. allow WAL to be sent to standbys before the
> > primary has finished flushing it locally. Which requires similar
> > infrastructure to what we're discussing here.
>
> I think this is a good point. After all, WALRead() has the following
> comment:
>
> * XXX probably this should be improved to suck data directly from the
> * WAL buffers when possible.
>
> Once you have all the infrastructure for that, holding back WAL replay on
> async standbys based on synchronous replication might be relatively easy.
That is, (as my understanding) async standbys are required to allow
overwriting existing unreplayed records after reconnection. But,
putting aside how to remember that LSN, if that happens at a segment
boundary, the async replica may run into the similar situation with
the missing-contrecord case. But standby cannot insert any original
record to get out from that situation.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
