On 2024-06-06 Th 18:02, Jelte Fennema-Nio wrote:
On Wed, 5 Jun 2024 at 23:37, Tom Lane <t...@sss.pgh.pa.us> wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
That is, psql from the test instance 001_ssltests_34 opened a
connection to
the test server with the client port 50072 and it made using the port by
the server from the test instance 001_ssltests_30 impossible.
Oh. (kicks self)
D'oh.
Should we really be allocating ephemeral server ports in the range
41952..65535? Maybe we should be looking for an unallocated port
somewhere below 41952, and above, say, 32767, so we couldn't have a
client socket collision.
Hmm, are there really any standards about how these port numbers
are used?
I wonder if we don't need to just be prepared to retry the whole
thing a few times. Even if it's true that "clients" shouldn't
choose ports below 41952, we still have a small chance of failure
against a non-Postgres server starting up at the wrong time.
My suggestion would be to not touch the ephemeral port range at all
for these ports. In practice the ephemeral port range is used for
cases where the operating system assigns the port, and the application
doesn't care whot it is. Not for when you want to get a free port, but
want to know in advance which one it is.
For the PgBouncer test suite we do something similar as the PG its
perl tests do, but there we allocate a port between 10200 and 32768:
https://github.com/pgbouncer/pgbouncer/blob/master/test/utils.py#L192-L215
Sure theoretically it's possible to hit a rare case where another
server starts up at the wrong time, but that chance seems way lower
than a client starting up at the wrong time. Especially since there
aren't many servers that use a port with 5 digits.
Attached is a patch that updates the port numbers.
Makes sense to me.
I still think my patch to force TCP mode for the SSL test makes sense as
well.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
