Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group