On Tue, Nov 15, 2022 at 09:42:26AM +1300, Thomas Munro wrote: > 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.
Oh, I see. Since we don't check the apply position when determining whether to send a reply, tests may need to wait a full wal_receiver_status_interval. FWIW with my patch, the runtime of the src/test/recovery tests seems to be back to what it was on my machine, but I certainly wouldn't rule out scheduling luck. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
