Re: Suppressing useless wakeups in walreceiver

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
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
Date: 2022-10-05 07:57:00
Message-ID: 20221005075700.j5vcrw3nwcndqa5a@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2022-Oct-04, Nathan Bossart wrote:

> Here is an updated patch set with the following changes:
> * 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 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.)

> * I attempted to minimize the calls to GetCurrentTimestamp(). The WAL
> receiver code already calls this function pretty liberally, so I don't know
> if this is important, but perhaps it could make a difference for systems
> that don't have something like the vDSO to avoid real system calls.

Yeah, we are indeed careful about this in most places. Maybe it's not
particularly important in 2022 and also not particularly important for
walreceiver (again, except in the code paths that affect sync replicas),
but there's no reason not to continue to be careful until we discover
more widely that it doesn't matter.

> * I removed the 'tli' argument from functions that now have an argument for
> the non-shared state struct. The 'tli' is stored within the struct, so the
> extra argument is unnecessary.

+1 (This could also be in 0001, naturally.)

> One thing that still bugs me a little bit about 0002 is that the calls to
> GetCurrentTimestamp() feel a bit scattered and more difficult to reason
> about. AFAICT 0002 keeps 'now' relatively up-to-date, but it seems
> possible that a future change could easily disrupt that. I don't have any
> other ideas at the moment, though.


Álvaro Herrera PostgreSQL Developer —

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-10-05 08:05:07 Re: shadow variables - pg15 edition
Previous Message Michael Paquier 2022-10-05 07:50:25 Re: Move backup-related code to xlogbackup.c/.h