On Tue, Nov 15, 2022 at 8:01 AM Nathan Bossart <nathandboss...@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.
