I have experienced some brittleness in the regression test setup that
causes the tests to be run against a different server instance or fail
in confusing ways when you have multiple instances running.
For some historic reasons, I have my local scripts set up so that they
build development instances using the hardcoded port 65432. This will
cause a temp install regression test to attempt to use port 565432 which
will be rejected silently by pg_regress, which will then use its
hardcoded default 65432 (no relation to my 65432). If I have some other
instance already running on 65432, then this will fail in non-reassuring
ways such as
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 94178
============== creating database "regression" ==============
ERROR: database "regression" already exists
It evidently failed to realize that there is another postmaster already
running at that port and just ran its test setup routines against that
other instance.
If there is no database named "regression" on that other instance, then
it will happily go ahead and run its full test suite against that other
instance.
I see two problems here:
1) It fails to realize that it could not start its own temp instance
when another instance is already running.
2) It ignores the port specification almost silently.
Since ports above 49152 are for private use, I think it is valid to
configure test instances in that port range, but our regression test
setup does not handle that port range very well.
So even if I configured my local scripts to use ports that are all
different from each other and from 65432, this problem would still exist.
So, also,
2a) It has an undocumented hardcoded default port.
Any thoughts on how to fix this?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
