Re: Suppressing useless wakeups in walreceiver

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, alvherre(at)alvh(dot)no-ip(dot)org, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Suppressing useless wakeups in walreceiver
Date: 2022-11-14 19:01:27
Message-ID: 20221114190127.GA1465312@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, Nov 14, 2022 at 02:47:14PM +1300, Thomas Munro wrote:
> Ahh, I think I might have it. In the old coding, sendTime starts out
> as 0, which I think caused it to send its first reply message after
> the first 100ms sleep, and only after that fall into a cadence of
> wal_receiver_status_interval (10s) while idle. Our new coding won't
> send its first reply until start time + wal_receiver_status_interval.
> If I have that right, think we can get back to the previous behaviour
> by explicitly setting the first message time, like:

Good find!

> @@ -433,6 +433,9 @@ WalReceiverMain(void)
> for (int i = 0; i < NUM_WALRCV_WAKEUPS; ++i)
> WalRcvComputeNextWakeup(i, now);
> + /* XXX start with a reply after 100ms */
> + wakeup[WALRCV_WAKEUP_REPLY] = now + 100000;
> +
> /* Loop until end-of-streaming or error */
> Obviously that's bogus and racy (it races with wait_for_catchup, and
> it's slow, actually both sides are not great and really should be
> event-driven, in later work)...

Is there any reason we should wait for 100ms before sending the initial
reply? ISTM the previous behavior essentially caused the first reply (and
feedback message) to be sent at the first opportunity after streaming
begins. My instinct is to do something like the attached. I wonder if we
ought to do something similar in the ConfigReloadPending path in case
hot_standby_feedback is being turned on.

Nathan Bossart
Amazon Web Services:

Attachment Content-Type Size
send_initial_reply.patch text/x-diff 560 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-11-14 19:01:34 Re: [PoC] Let libpq reject unexpected authentication requests
Previous Message Robert Haas 2022-11-14 18:43:41 Re: Add sub-transaction overflow status in pg_stat_activity