Re: [PATCH] Allow Postgres to pick an unused port to listen - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCH] Allow Postgres to pick an unused port to listen
Date
Msg-id 00a339c9-9749-dcd5-edba-b0968b7159cb@dunslane.net
Whole thread Raw
In response to Re: [PATCH] Allow Postgres to pick an unused port to listen  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Allow Postgres to pick an unused port to listen
Re: [PATCH] Allow Postgres to pick an unused port to listen
List pgsql-hackers


On 2023-03-29 We 07:55, Tom Lane wrote:
Yurii Rashkovskii <yrashk@gmail.com> writes:
I would like to suggest a patch against master (although it may be worth
backporting it) that makes it possible to listen on any unused port.
I think this is a bad idea, mainly because this:

Instead, with this patch, one can specify `port` as `0` (the "wildcard"
port) and retrieve the assigned port from postmaster.pid
is a horrid way to find out what was picked, and yet there could
be no other.

Our existing design for this sort of thing is to let the testing
framework choose the port, and I don't really see what's wrong
with that approach.  Yes, I know it's theoretically subject to
race conditions, but that hasn't seemed to be a problem in
practice.  It's especially not a problem given that modern
testing practice tends to not open any TCP port at all, just
a Unix socket in a test-private directory, so that port
conflicts are a non-issue.


For TAP tests we have pretty much resolved the port collisions issue for TCP ports too. See commit 9b4eafcaf4

Perhaps the OP could adapt that logic to his use case.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Should vacuum process config file reload more often
Next
From: Thomas Munro
Date:
Subject: Re: Direct I/O