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 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 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. -- With Regards, Amit Kapila.
