From: Tom Lane <tgl@sss.pgh.pa.us>
To: a.mitrokhin@postgrespro.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)
In-reply-to: <824bbf6be5fa0edf6a7d4c8371ce67ce@postgrespro.ru>
References: <824bbf6be5fa0edf6a7d4c8371ce67ce@postgrespro.ru>
Comments: In-reply-to a.mitrokhin@postgrespro.ru
	message dated "Thu, 10 Jul 2025 14:15:19 +0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1523823.1752158490.1@sss.pgh.pa.us>
Date: Thu, 10 Jul 2025 10:41:30 -0400
Message-ID: <1523824.1752158490@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1523824.1752158490%40sss.pgh.pa.us>
Precedence: bulk

a.mitrokhin@postgrespro.ru writes:
> Postgres does not allow starting the server with port=0, which prevents
> it from obtaining an arbitrary free port from the kernel.

Others have already pointed out problems with this proposal, but
the one I see is: what do you do next?  How will clients know
what port to connect to?

The only way I could see to do that is to read the port out of
postmaster.pid, which works only for clients running as the same
userid as the postmaster, which is surely an unfit-for-production
approach.

If you're only interested in this for testing purposes, we
already have perfectly good free-port-selection algorithms
embedded in our test harnesses.  For that matter, in a test
environment it's usually best (most secure) to use a Unix
socket in a private directory, in which case there is little
need to worry about port number conflicts in the first place.

			regards, tom lane