|From:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|To:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|Cc:||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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
Amazon Web Services: https://aws.amazon.com
|Next Message||Andres Freund||2022-10-05 18:20:50||Re: Add meson.build to version_stamp.pl|
|Previous Message||Alvaro Herrera||2022-10-05 17:58:21||Re: Move backup-related code to xlogbackup.c/.h|