Re: Suppressing useless wakeups in walreceiver

Thanks for taking a look.

On Wed, Oct 05, 2022 at 09:57:00AM +0200, Alvaro Herrera wrote:
> On 2022-Oct-04, Nathan Bossart wrote:
>> * The creation of the struct for non-shared WAL receiver state is moved to
>> a prerequisite 0001 patch. This should help ease review of 0002 a bit.
>
> I think that would be even better if you moved the API adjustments of
> some functions for the new struct to 0001 as well
> (XLogWalRcvSendHSFeedback etc).

I moved as much as I could to 0001 in v4.

>> * I updated the nap time calculation to round up to the next millisecond,
>> as discussed upthread.
>
> I didn't look at this part very carefully, but IIRC walreceiver's
> responsivity has a direct impact on latency for sync replicas. Maybe
> it'd be sensible to the definition that the sleep time is rounded down
> rather than up? (At least, for the cases where we have something to do
> and not merely continue sleeping.)

The concern is that if we wake up early, we'll end up spinning until the
wake-up time is reached. Given the current behavior is to sleep for 100ms
at a time, and the tasks in question are governed by wal_receiver_timeout
and wal_receiver_status_interval (which are typically set to several
seconds) it seems reasonably safe to sleep up to an extra ~1ms here and
there without sacrificing responsiveness. In fact, I imagine this patch
results in a net improvement in responsiveness for these tasks.

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