Date: Thu, 15 Dec 2022 14:52:32 +0900 (JST)
Message-Id: <20221215.145232.3863147473914608.horikyota.ntt@gmail.com>
To: amit.kapila16@gmail.com
Cc: kuroda.hayato@fujitsu.com, osumi.takamichi@fujitsu.com,
 vignesh21@gmail.com, euler@eulerto.com, m.melihmutlu@gmail.com,
 andres@anarazel.de, marcos@f10.com.br, pgsql-hackers@postgresql.org,
 smithpb2250@gmail.com
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: 
 <CAA4eK1JmayanpdQaJnabYLcK8qnsp7YoOnWzd3n0qUzzQfxmkw@mail.gmail.com>
References: 
 <CAA4eK1LhE0iBtJ76u+efRkSB_n7t_bsR=ZVjrxVGfLoQ4JyuqA@mail.gmail.com>
	<20221215.134152.1754454051761023771.horikyota.ntt@gmail.com>
	<CAA4eK1JmayanpdQaJnabYLcK8qnsp7YoOnWzd3n0qUzzQfxmkw@mail.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/20221215.145232.3863147473914608.horikyota.ntt%40gmail.com>
Precedence: bulk

At Thu, 15 Dec 2022 10:29:17 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in 
> On Thu, Dec 15, 2022 at 10:11 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > At Thu, 15 Dec 2022 09:18:55 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
> > > On Thu, Dec 15, 2022 at 7:22 AM Kyotaro Horiguchi
> > > <horikyota.ntt@gmail.com> wrote:
> > > subscriber was busy enough that it doesn't need to add an additional
> > > delay before applying a particular transaction(s) but adding a delay
> > > to such a transaction on the publisher will actually make it take much
> > > longer to reflect than expected. We probably need to name this
> >
> > Isn't the name min_apply_delay implying the same behavior? Even though
> > the delay time will be a bit prolonged.
> >
> 
> Sorry, I don't understand what you intend to say in this point. In
> above, I mean that the currently proposed patch won't have such a
> problem but if we apply delay on publisher the problem can happen.

Are you saing about the sender-side delay lets the whole transaction
(if it have not streamed out) stay on the sender side?  If so... yeah,
I agree that it is undesirable.

> > > parameter as min_send_delay if we want to do what you are saying and
> > > then I don't know if it serves the actual need and also it will be
> > > different from what we do in physical standby.
> >
> > In the first place phisical and logical replication works differently
> > and the mechanism to delaying "apply" differs even in the current
> > state in terms of logrep delay choking stream.
> >
> 
> I think the first preference is to make it work in a similar way (as
> much as possible) to how this parameter works in physical standby and
> if that is not at all possible then we may consider other approaches.

I uderstood that. However, still I think choking the stream on the
receiver-side alone is kind of ugly since it is breaking the protocol
assumption, that is, the in-band maintenance packets are processed in
a on-time manner on the peer under normal operation (even though
involving some delays for some natural reasons).  In this regard, I
inclined to be in favor of Kuroda-san'sproposal..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center