pg_upgrade test script creates port conflicts in parallel testing

I've been getting complaints lately about failures of parallel builds
of the Fedora Postgres RPMs on the same machine. I just figured out
what's going on: the pg_upgrade regression test script starts test
postmasters using the default value of listen_addresses, which means
that they try to bind to TCP port 50432 on localhost, which means the
test fails if there's more than one concurrent instance. This does
not happen for the main regression tests, nor for any other contrib
module, because pg_regress.c's postmaster-starting code explicitly
sets listen_addresses to empty, so that only the Unix socket is
active. (RPM building in Fedora generally happens in a chroot, so
there is no conflict of Unix sockets - they're not in the same /tmp.)

pg_upgrade itself also sets listen_addresses to empty; it's only
the test script that hasn't gotten the memo.

Does anyone have an objection to fixing the pg_upgrade test script
to suppress the TCP socket?

regards, tom lane

On 01/03/2013 12:58 PM, Tom Lane wrote:
> I've been getting complaints lately about failures of parallel builds
> of the Fedora Postgres RPMs on the same machine. I just figured out
> what's going on: the pg_upgrade regression test script starts test
> postmasters using the default value of listen_addresses, which means
> that they try to bind to TCP port 50432 on localhost, which means the
> test fails if there's more than one concurrent instance. This does
> not happen for the main regression tests, nor for any other contrib
> module, because pg_regress.c's postmaster-starting code explicitly
> sets listen_addresses to empty, so that only the Unix socket is
> active. (RPM building in Fedora generally happens in a chroot, so
> there is no conflict of Unix sockets - they're not in the same /tmp.)
>
> pg_upgrade itself also sets listen_addresses to empty; it's only
> the test script that hasn't gotten the memo.
>
> Does anyone have an objection to fixing the pg_upgrade test script
> to suppress the TCP socket?
>
>

Should be OK. We can't do that on Windows, though, so please make it
conditional so we don't break Mingw buildfarm members. The test script
already contains a few Windows variants.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 01/03/2013 12:58 PM, Tom Lane wrote:
>> Does anyone have an objection to fixing the pg_upgrade test script
>> to suppress the TCP socket?

> Should be OK. We can't do that on Windows, though, so please make it
> conditional so we don't break Mingw buildfarm members. The test script
> already contains a few Windows variants.

I'm planning to do it like this:

testhost=`uname -s`

+case $testhost in
+ MINGW*) LISTEN_ADDRESSES="localhost" ;;
+ *) LISTEN_ADDRESSES="" ;;
+esac
+
+POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES"
+
temp_root=$PWD/tmp_check

which matches the existing Windows-specific switches.

regards, tom lane