On Fri, Feb 10, 2023 at 6:27 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Thu, 9 Feb 2023 13:48:52 +0530, Amit Kapila <amit.kapil...@gmail.com> > wrote in > > On Thu, Feb 9, 2023 at 10:45 AM Kyotaro Horiguchi > > <horikyota....@gmail.com> wrote: > > > > > > At Wed, 8 Feb 2023 09:03:03 +0000, "Hayato Kuroda (Fujitsu)" > > > <kuroda.hay...@fujitsu.com> wrote in > > > > Thank you for reviewing! PSA new version. > > > > > > + if (statusinterval_ms > 0 && diffms > statusinterval_ms) > > > > > > The next expected feedback time is measured from the last status > > > report. Thus, it seems to me this may suppress feedbacks from being > > > sent for an unexpectedly long time especially when min_apply_delay is > > > shorter than wal_r_s_interval. > > > > > > > I think the minimum time before we send any feedback during the wait > > is wal_r_s_interval. Now, I think if there is no transaction for a > > long time before we get a new transaction, there should be keep-alive > > messages in between which would allow us to send feedback at regular > > intervals (wal_receiver_status_interval). So, I think we should be > > Right. > > > able to send feedback in less than 2 * wal_receiver_status_interval > > unless wal_sender/receiver timeout is very large and there is a very > > low volume of transactions. Now, we can try to send the feedback > > 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? The one simple idea as I shared in my last email was to send feedback every wal_receiver_status_interval / 2. I think this should avoid any timeout problem because we already recommend setting it to lesser than wal_sender_timeout. -- With Regards, Amit Kapila.