Re: A test for replay of regression tests

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