Re: pg_upgrade test script creates port conflicts in parallel testing

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: pg_upgrade test script creates port conflicts in parallel testing
Date: 2013-01-03 18:36:15
Message-ID: 50E5CF9F.9030605@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2013-01-03 19:31:32 Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Previous Message Josh Berkus 2013-01-03 18:35:22 Re: Feature Request: pg_replication_master()