From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ssl tests fail due to TCP port conflict |
Date: | 2024-06-06 01:23:40 |
Message-ID: | a6d5cf78-6cf0-473d-a0f2-5e85b90bf1b6@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-06-05 We 17:37, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.
Yeah, I think you're right. One thing we should do is be careful to use
the port as soon as possible after we have picked it, to reduce the
possibility that something else will use it first.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-06-06 01:50:32 | Re: [multithreading] extension compatibility |
Previous Message | Robert Haas | 2024-06-06 01:10:01 | Re: [multithreading] extension compatibility |