Date: Mon, 14 Mar 2022 11:41:55 +0900 (JST)
Message-Id: <20220314.114155.1987239955710692813.horikyota.ntt@gmail.com>
To: nathandbossart@gmail.com
Cc: andres@anarazel.de, bharath.rupireddyforpostgres@gmail.com,
 satyanarlapuram@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Allow async standbys wait for sync replication
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <20220314.113002.1607014104756351937.horikyota.ntt@gmail.com>
References: <20220309020123.sneaoijlg3rszvst@alap3.anarazel.de>
	<20220312223332.GA921069@nathanxps13>
	<20220314.113002.1607014104756351937.horikyota.ntt@gmail.com>
User-Agent: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20220314.114155.1987239955710692813.horikyota.ntt%40gmail.com>
Precedence: bulk

At Mon, 14 Mar 2022 11:30:02 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> 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.

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