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

From Alvaro Herrera
Subject Re: [PATCH] Allow Postgres to pick an unused port to listen
Date
Msg-id 20230508144301.tr2kvlihqddwp6ss@alvherre.pgsql
Whole thread Raw
In response to Re: [PATCH] Allow Postgres to pick an unused port to listen  (Yurii Rashkovskii <yrashk@gmail.com>)
Responses Re: [PATCH] Allow Postgres to pick an unused port to listen
List pgsql-hackers
On 2023-Apr-19, Yurii Rashkovskii wrote:

> If we consider this path, then (if we assume the format of the file is
> still to be private), we can make the port line accept multiple ports using
> a delimiter like `:` so that the next line still remains the same.

This made me wonder if storing the unadorned port number is really the
best way.  Suppose we did extend things so that we listen on different
ports on different interfaces; how would this scheme work at all?  I
suspect it would be simpler to store both the interface address and the
port, perhaps separated by :.  You would keep it to one pair per line,
so you'd get the IPv6 address/port separately from the IPv4 address, for
example.  And if you happen to have multiple addresses, you know exactly
which ones you're listening on.

To match a problem that has been discussed in the lists previously,
suppose you have listen_addresses='localhost' and the resolver does
funny things with that name (say you mess up /etc/hosts after starting).
Things would be much simpler if you knew exactly what the resolver did
at postmaster start time.

> (I consider this feature so small that it doesn't deserve such a lengthy
> discussion. However, I also get Tom's point about how we document this

You should see the discussion that led to the addition of psql's 'exit'
command sometime:

https://www.postgresql.org/message-id/flat/CALVFHFb-C_5_94hueWg6Dd0zu7TfbpT7hzsh9Zf0DEDOSaAnfA%40mail.gmail.com#949321e44856b7fa295834d6a3997ab4


-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Every machine is a smoke machine if you operate it wrong enough."
https://twitter.com/libseybieda/status/1541673325781196801



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: benchmark results comparing versions 15.2 and 16
Next
From: Bharath Rupireddy
Date:
Subject: Re: WAL Insertion Lock Improvements