I wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On Fri, 2013-05-03 at 21:23 -0400, Tom Lane wrote:
>>> This patch appears to have broken the ability to run "make check"
>>> for pg_upgrade when there's an installed server running at the build's
>>> default PGPORT. I get a bleat about how the port is already in use...
>> Still works for me:
>> make check PGPORT=55555
>> What were you using?
> Just "make check". Why should I have to do something else?
To press the point a little bit: IMO it's a bad idea for pg_upgrade,
alone among contrib modules, to require manual management of the port
choice during "make check". In every other contrib module, pg_regress.c
will go to quite substantial lengths to pick an unused port number for
the temporary installation. I object to having contrib/pg_upgrade
break that for what appears to be no reason at all. I also note that
the pg_upgrade test script, like pg_regress, intentionally unsets every
other libpq connection-control environment variable; so it's quite
unclear why it should honor an external setting for this one.
It's probably not really necessary for the test script to try to
duplicate the dynamic port-number testing done in pg_regress.c
(especially since that isn't terribly bulletproof anyway). However,
I think it should at least replicate this bit of logic:
/*
* To reduce chances of interference with parallel installations, use
* a port number starting in the private range (49152-65535)
* calculated from the version number.
*/
port = 0xC000 | (PG_VERSION_NUM & 0x3FFF);
since that should only take a couple of lines of shell scripting,
and is enough to avoid collisions in ordinary cases.
Barring objection, I'm going to revert
3d53173e20d151341f894f79d556768c845ba3e4 and do that instead.
regards, tom lane