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
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 |