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: https://aws.amazon.com