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
