On Wed, Apr 13, 2016 at 9:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> While we wait to see if that actually helps give useful errors,
> I had a thought about what may be happening here.  PostgresNode.pm
> picks a random high port number and tests to see if it's free using
> pg_isready, with (unless I'm misreading) any non-zero result code
> being taken as "it's free".  The problem here is that that completely
> fails to recognize a port being used by a non-Postgres process as
> not-free --- most likely, you'll get PQPING_NO_RESPONSE for that case.
> If there's other stuff using high ports on a particular buildfarm machine,
> you'd expect occasional random test failures due to this.  The observed
> fact that some buildfarm critters are much more prone to this type of
> failure than others is well explained by this hypothesis.

Each test run uses its own custom unix_socket_directories, PGHOST is
enforced to use it, and all the port tests go through that as well.
And it seems to me that the same port number can be used as long as
the socket directory is different, no? At least that's how
PostgresNode has been designed to work, and this is useful when
running tests in parallel to avoid port and host collision.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to