Hi, On 2022-01-27 12:47:08 -0800, Andres Freund wrote: > > I have noticed on a different setup that this test adds 11 minutes to the > > runtime of the recovery tests, effectively doubling it. The doubling is > > roughly true on faster setups, too > > Does a normal regress run take roughly that long? Or is the problem that the > 027_stream_regress.pl ends up defaulting to shared_buffers=1MB, causing lots > of unnecessary IO?
In my msys install a normal regress run takes 57s, 027_stream_regress.pl takes 194s. It's *not* shared_buffers. Or any of the other postgresql.conf settings. As far as I can tell. < tries a bunch of things > ARGH. It's the utterly broken handling of refused connections on windows. The pg_regress invocation doesn't specify the host address, just the port. Now you might reasonably ask, why does that slow things down so much, rather than working or not working? The problem is that a tcp connect() on windows doesn't immediately fail when a connection establishment is rejected, but instead internally retries several times. Which takes 2s. The reason there are rejected connections without specifying the host is that Cluster.pm configures to listen to 127.0.0.1. But the default for libpq/psql is to try "localhost". Which name resolution returns first as ipv6 (i.e. ::1). Which takes 2s to fail, upon which libpq goes and tries 127.0.0.1, which works. That means every single psql started by 027_stream_regress.pl's pg_regress takes 2s. Which of course adds up... I'll go and sob in a corner. Greetings, Andres Freund
