On Tue, Nov 15, 2022 at 8:01 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> 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.
That works for 020_pg_receivewal. I wonder if there are also tests
that stream a bit of WAL first and then do wait_for_catchup that were
previously benefiting from the 100ms-after-startup message by
scheduling luck (as in, that was usually enough for replay)? I might
go and teach Cluster.pm to log how much time is wasted in
wait_for_catchup to get some observability, and then try to figure out
how to optimise it properly. We could perhaps put the 100ms duct tape
back temporarily though, if necessary.
