Re: [PATCH] Allow Postgres to pick an unused port to listen

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Yurii Rashkovskii <yrashk(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Cary Huang <cary(dot)huang(at)highgo(dot)ca>
Subject: Re: [PATCH] Allow Postgres to pick an unused port to listen
Date: 2023-05-08 14:43:01
Message-ID: 20230508144301.tr2kvlihqddwp6ss@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2023-05-08 14:48:04 Re: WAL Insertion Lock Improvements
Previous Message Alexander Lakhin 2023-05-08 13:00:01 Re: benchmark results comparing versions 15.2 and 16