Date: Thu, 16 Feb 2023 17:55:46 +0900 (JST)
Message-Id: <20230216.175546.98020490115903046.horikyota.ntt@gmail.com>
To: kuroda.hayato@fujitsu.com
Cc: andres@anarazel.de, amit.kapila16@gmail.com, smithpb2250@gmail.com,
 shiy.fnst@fujitsu.com, vignesh21@gmail.com, shveta.malik@gmail.com,
 osumi.takamichi@fujitsu.com, dilipbalaut@gmail.com, euler@eulerto.com,
 m.melihmutlu@gmail.com, marcos@f10.com.br, pgsql-hackers@postgresql.org
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <TYAPR01MB5866A2D600A86F743DDF8FE5F5A09@TYAPR01MB5866.jpnprd01.prod.outlook.com>
References: <TYAPR01MB5866A9A39100EDA85E612B3EF5A39@TYAPR01MB5866.jpnprd01.prod.outlook.com>
	<20230216.142101.1198410163394123325.horikyota.ntt@gmail.com>
	<TYAPR01MB5866A2D600A86F743DDF8FE5F5A09@TYAPR01MB5866.jpnprd01.prod.outlook.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/20230216.175546.98020490115903046.horikyota.ntt%40gmail.com>
Precedence: bulk

At Thu, 16 Feb 2023 06:20:23 +0000, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote in 
> Dear Horiguchi-san,
> 
> Thank you for responding! Before modifying patches, I want to confirm something
> you said.
> 
> > As Amit-K mentioned, we may need to change the name of the option in
> > this version, since the delay mechanism in this version causes a delay
> > in sending from publisher than delaying apply on the subscriber side.
> 
> Right, will be changed.
> 
> > I'm not sure why output plugin is involved in the delay mechanism. It
> > appears to me that it would be simpler if the delay occurred in
> > reorder buffer or logical decoder instead.
> 
> I'm planning to change, but..

Yeah, I don't think we've made up our minds about which way to go yet,
so it's a bit too early to work on that.

> > Perhaps what I understand
> > correctly is that we could delay right before only sending commit
> > records in this case. If we delay at publisher end, all changes will
> > be sent at once if !streaming, and otherwise, all changes in a
> > transaction will be spooled at subscriber end. In any case, apply
> > worker won't be holding an active transaction unnecessarily.
> 
> What about parallel case? Latest patch does not reject the combination of parallel
> streaming mode and delay. If delay is done at commit and subscriber uses an parallel
> apply worker, it may acquire lock for a long time.

I didn't looked too closely, but my guess is that transactions are
conveyed in spool files in parallel mode, with each file storing a
complete transaction.

> > Of
> > course we need add the mechanism to process keep-alive and status
> > report messages.
> 
> Could you share the good way to handle keep-alive and status messages if you have?
> If we changed to the decoding layer, it is strange to call walsender function
> directly.

I'm sorry, but I don't have a concrete idea at the moment. When I read
through the last patch, I missed that WalSndDelay is actually a subset
of WalSndLoop. Although it can handle keep-alives correctly, I'm not
sure we can accept that structure..

> > Those setups work fine when no
> > apply-delay involved, but they won't work with the patches we're
> > talking about because the subscriber won't respond to the keep-alive
> > packets from the peer.  So when I wrote "practically works" in the
> > last mail, this is what I meant.
> 
> I'm not sure around the part. I think in the latest patch, subscriber can respond
> to the keepalive packets from the peer. Also, publisher can respond to the peer.
> Could you please tell me if you know a case that publisher or subscriber cannot
> respond to the opposite side? Note that if we apply the publisher-side patch, we
> don't have to apply subscriber-side patch.

Sorry about that again, I missed that part in the last patch as
mentioned earlier..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center