Horton
Menu

Thread

  1. Starting a PostgreSQL server on a dynamic port (parameter port=0)

    a.mitrokhin@postgrespro.ru — 2025-07-10T07:15:19Z

    Hello.


Postgres does not allow starting the server with port=0, which prevents
it from obtaining an arbitrary free port from the kernel.


~$ LANG=C pg_ctl -D data -o "-c port=0" start
2025-07-10 05:27:02.785 GMT [702503] FATAL:  0 is outside the valid
range for parameter "port" (1 .. 65535)


This makes it unreliable to start the server in my tests without the
risk of port conflicts with already running programs, unless resorting
to an unreliable and race-condition-prone procedure of reserving ports
in advance.


Could you please fix this?

  2. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    Kirill Reshke <reshkekirill@gmail.com> — 2025-07-10T07:46:55Z

    On Thu, 10 Jul 2025 at 12:15, <a.mitrokhin@postgrespro.ru> wrote:
>
> Hello.
>
>
> Postgres does not allow starting the server with port=0, which prevents
> it from obtaining an arbitrary free port from the kernel.
>
>
> ~$ LANG=C pg_ctl -D data -o "-c port=0" start
> 2025-07-10 05:27:02.785 GMT [702503] FATAL:  0 is outside the valid
> range for parameter "port" (1 .. 65535)
>
>
> This makes it unreliable to start the server in my tests without the
> risk of port conflicts with already running programs, unless resorting
> to an unreliable and race-condition-prone procedure of reserving ports
> in advance.
>
>
> Could you please fix this?


Regression tests somehow solve this problem without any patch, so why
this should be fixed?

-- 
Best regards,
Kirill Reshke

  3. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    a.mitrokhin@postgrespro.ru — 2025-07-10T08:29:53Z

    Kirill Reshke писал(а) 2025-07-10 14:46:
> On Thu, 10 Jul 2025 at 12:15, <a.mitrokhin@postgrespro.ru> wrote:
>> 
>> Hello.
>> 
>> 
>> Postgres does not allow starting the server with port=0, which 
>> prevents
>> it from obtaining an arbitrary free port from the kernel.
>> 
>> 
>> ~$ LANG=C pg_ctl -D data -o "-c port=0" start
>> 2025-07-10 05:27:02.785 GMT [702503] FATAL:  0 is outside the valid
>> range for parameter "port" (1 .. 65535)
>> 
>> 
>> This makes it unreliable to start the server in my tests without the
>> risk of port conflicts with already running programs, unless resorting
>> to an unreliable and race-condition-prone procedure of reserving ports
>> in advance.
>> 
>> 
>> Could you please fix this?
> 
> 
> Regression tests somehow solve this problem without any patch, so why
> this should be fixed?

This has nothing to do with Postgres regression tests. The issue is
the practical benefit of using a dynamic port, which we're depriving
ourselves of.

If you're not interested in this behavior, you'll never use it. But
there are cases where it can be very convenient. Why artificially
restrict functionality that is simple, doesn't conflict with anything,
and has no negative side effects?

  4. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    Laurenz Albe <laurenz.albe@cybertec.at> — 2025-07-10T08:53:17Z

    On Thu, 2025-07-10 at 15:29 +0700, a.mitrokhin@postgrespro.ru wrote:
> > > Postgres does not allow starting the server with port=0, which prevents
> > > it from obtaining an arbitrary free port from the kernel.
> 
> This has nothing to do with Postgres regression tests. The issue is
> the practical benefit of using a dynamic port, which we're depriving
> ourselves of.
> 
> If you're not interested in this behavior, you'll never use it. But
> there are cases where it can be very convenient. Why artificially
> restrict functionality that is simple, doesn't conflict with anything,
> and has no negative side effects?

I have never wished for such a feature, and I can see negative side
effects.  If the server listens on a different port than you expect,
it is easier to connect to the wrong server by mistake.

Yours,
Laurenz Albe

  5. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    Jim Jones <jim.jones@uni-muenster.de> — 2025-07-10T09:13:31Z

    
On 10.07.25 10:53, Laurenz Albe wrote:
> I have never wished for such a feature, and I can see negative side
> effects.  If the server listens on a different port than you expect,
> it is easier to connect to the wrong server by mistake.

Moreover, there's a risk that postgres could potentially hijack the port
of an application that's not currently running, but has a fixed port
configuration assigned to it. This could, in turn, prevent the
application from starting up successfully.

I can understand why it might be attractive for some scenarios, but the
risks and consequences could outweigh the benefits.

Best, Jim

  6. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    David G. Johnston <david.g.johnston@gmail.com> — 2025-07-10T13:21:45Z

    On Thursday, July 10, 2025, <a.mitrokhin@postgrespro.ru> wrote:

>
> If you're not interested in this behavior, you'll never use it. But
> there are cases where it can be very convenient. Why artificially
> restrict functionality that is simple, doesn't conflict with anything,
> and has no negative side effects?
>

Then figure out how to do it on all the OSes we support and propose a
patch.  Maybe it’s simple enough to include.  Maybe not.  If it is simple e
on an OS one cares about a shell script around pg_ctl is a simple way to
leverage it so it’s still a fairly low priority to add into core.

David J.

  7. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    Euler Taveira <euler@eulerto.com> — 2025-07-10T14:12:22Z

    On Thu, Jul 10, 2025, at 10:21 AM, David G. Johnston wrote:
> On Thursday, July 10, 2025, <a.mitrokhin@postgrespro.ru> wrote:
>> 
>> If you're not interested in this behavior, you'll never use it. But
>> there are cases where it can be very convenient. Why artificially
>> restrict functionality that is simple, doesn't conflict with anything,
>> and has no negative side effects?
>
> Then figure out how to do it on all the OSes we support and propose a 
> patch.  Maybe it’s simple enough to include.  Maybe not.  If it is 
> simple e on an OS one cares about a shell script around pg_ctl is a 
> simple way to leverage it so it’s still a fairly low priority to add 
> into core.
>

I don't think it is just a matter of operating system supports it. Linux and
Windows supports port 0 but FreeBSD does not.

The RFC 63335 [1] that is referred in the IANA document [2] says:

Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future.

Some operating systems like Linux and Windows decided to use it to
automatically assign a free port. I don't think it is a good idea for
production. The main reason is security, we had some reports[3][4] in the past.
Some services like apache and nginx that don't allow you to use port 0.

IMO it could be supported for development purposes. However, the test suite
(pg_regress and TAP tests) already has some logic to assign a port from the
private range (49152-65535) and is capable of assigning another port if the
current port is in use. Maybe the OP has a case that the current approach is
not ideal.

[1] https://www.rfc-editor.org/rfc/rfc6335.html
[2] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
[3] https://medium.com/@ian.barwise/socket-programming-the-bizarre-tcp-ip-port-0-saga-b5c302d04299
[4] https://nvd.nist.gov/vuln/detail/cve-2023-27567#:~:text=Description,rule%20can%20crash%20the%20kernel.


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/

  8. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-07-10T14:41:30Z

    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

  9. Re: Starting a PostgreSQL server on a dynamic port (parameter port=0)

    a.mitrokhin@postgrespro.ru — 2025-07-11T07:11:43Z

    Tom Lane писал(а) 2025-07-10 21:41:
> 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.
> 

I looked at get_free_port(). Here's how it works:
     - It selects a port from the range 10200..32767,
     - Checks that the port is not in use, and
     - Verifies there’s no file created for that reserved port.

There’s a race condition between bind() and the actual process
launch, and it’s not handled (I don’t think there’s a simple
solution with this approach). The port could be taken by any
connection in the system or by another developer running their
own tests on the same host (and they likely have their own
directory with port reservation files).

It would be much simpler to just start the server and use the
port assigned by the OS kernel. The vast majority of test
scenarios would work fine this way (I believe).