Re: Suppressing useless wakeups in walreceiver

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Suppressing useless wakeups in walreceiver
Date: 2022-10-13 17:45:06
Message-ID: 20221013174506.GA1550162@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 13, 2022 at 03:35:14PM +0530, Bharath Rupireddy wrote:
> I think the hot standby feedback message gets sent too frequently
> without honouring the wal_receiver_status_interval because the 'now'
> is actually not the current time with your patch but 'now +
> XLogWalRcvSendReply()'s time'. However, it's possible that I may be
> wrong here.

Is your concern that the next wakeup time will be miscalculated because of
a stale value in 'now'? I think that's existing behavior, as we save the
current time before sending the message in XLogWalRcvSendReply and
XLogWalRcvSendHSFeedback. The only way to completely avoid this would be
to call GetCurrentTimestamp() after the message has been sent and to use
that value to calculate when the next message should be sent. However, I
am skeptical there's really any practical impact. Is it really a problem
if a message that should be sent every 30 seconds is sent at an interval of
29.9 seconds sometimes? I think it could go the other way, too. If 'now'
is stale, we might decide not to send a feedback message until the next
loop iteration, so the interval might be 30.1 seconds. I don't think it's
realistic to expect complete accuracy here.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-10-13 17:55:08 remove redundant memset() call
Previous Message Jacob Champion 2022-10-13 17:30:37 Re: Support tls-exporter as channel binding for TLSv1.3