Hi, Horiguchi-san
On Monday, February 13, 2023 10:26 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > At Fri, 10 Feb 2023 10:34:49 +0530, Amit Kapila <amit.kapil...@gmail.com> > wrote in > > On Fri, Feb 10, 2023 at 10:11 AM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > > > > On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi > > > <horikyota....@gmail.com> wrote: > > > > We have suffered this kind of feedback silence many times. Thus I > > > > don't want to rely on luck here. I had in mind of exposing > > > > last_send itself or providing interval-calclation function to the logic. > > > > > > I think we have last_send time in send_feedback(), so we can expose > > > it if we want but how would that solve the problem you are worried > about? > > Wal receiver can avoid a too-long sleep by knowing when to wake up for the > next feedback. > > > I have an idea to use last_send time to avoid walsenders being > > timeout. Instead of directly using wal_receiver_status_interval as a > > minimum interval to send the feedback, we should check if it is > > greater than last_send time then we should send the feedback after > > (wal_receiver_status_interval - last_send). I think they can probably > > be different only on the very first time. Any better ideas? > > If it means MyLogicalRepWorker->last_send_time, it is not the last time when > walreceiver sent a feedback but the last time when > wal*sender* sent a data. So I'm not sure that works. > > We could use the variable that way, but AFAIU in turn when so many changes > have been spooled that the control doesn't return to LogicalRepApplyLoop > longer than wal_r_s_interval, maybe_apply_delay() starts calling > send_feedback() at every call after the first feedback timing. Even in that > case, send_feedback() won't send one actually until the next feedback timing, > I don't think that behavior is great. > > The only packets walreceiver sends back is the feedback packets and > currently only send_feedback knows the last feedback time. Thanks for your comments ! As described in your last sentence, in the latest patch v34 [1], we use the last time set in send_feedback() and based on it, we calculate and adjust the first timing of feedback message in maybe_apply_delay() so that we can send the feedback message following the interval of wal_receiver_status_interval. I wasn't sure if the above concern is still valid for this implementation. Could you please have a look at the latest patch and share your opinion ? [1] - https://www.postgresql.org/message-id/TYCPR01MB83736C50C98CB2153728A7A8EDDE9%40TYCPR01MB8373.jpnprd01.prod.outlook.com Best Regards, Takamichi Osumi
