Re: Allow async standbys wait for sync replication

At Mon, 14 Mar 2022 11:30:02 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Sat, 12 Mar 2022 14:33:32 -0800, Nathan Bossart <nathandbossart(at)gmail(dot)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.

Just to make sure and a bit off from the topic, I think the
optimization itself is quite promising and want to have.

> 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