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: > > > > > > At Wed, 14 Dec 2022 16:30:28 +0530, Amit Kapila <amit.kapil...@gmail.com> > > > wrote in > > > > On Wed, Dec 14, 2022 at 4:16 PM Hayato Kuroda (Fujitsu) > > > > <kuroda.hay...@fujitsu.com> wrote: > > > > > One idea to avoid that is to send the min_apply_delay subscriber > > > > > option to publisher > > > > > and compare them, but it may be not sufficient. Because XXX_timout > > > > > GUC parameters > > > > > could be modified later. > > > > > > > > > > > > > How about restarting the apply worker if min_apply_delay changes? Will > > > > that be sufficient? > > > > > > Mmm. If publisher knows that value, isn't it albe to delay *sending* > > > data in the first place? This will resolve many known issues including > > > walsender's un-terminatability, possible buffer-full and status packet > > > exchanging. > > > > > > > Yeah, but won't it change the meaning of this parameter? Say the > > Internally changes, but does not change on its face. The difference is > only in where the choking point exists. If ".._apply_delay" should > work literally, we should go the way Kuroda-san proposed. Namely, > "apply worker has received the data, but will deilay applying it". If > we technically name it correctly for the current behavior, it would be > "min_receive_delay" or "min_choking_interval". > > > 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. > > 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. -- With Regards, Amit Kapila.
