At Thu, 15 Dec 2022 10:29:17 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in > On Thu, Dec 15, 2022 at 10:11 AM Kyotaro Horiguchi > <horikyota....@gmail.com> wrote: > > > > At Thu, 15 Dec 2022 09:18:55 +0530, Amit Kapila <amit.kapil...@gmail.com> > > wrote in > > > On Thu, Dec 15, 2022 at 7:22 AM Kyotaro Horiguchi > > > <horikyota....@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