On 2024-06-05 We 16:49, Andrew Dunstan wrote:
On 2024-06-05 We 16:00, Alexander Lakhin wrote:
Hello Andrew,
05.06.2024 21:10, Andrew Dunstan wrote:
I think I see what's going on here. It looks like it's because we
start the server in unix socket mode, and then switch to using TCP
as well.
Can you try your test with this patch applied and see if the problem
persists? If we start in TCP mode the framework should test for a
port clash.
It seems that the failure rate decreased (I guess the patch rules out
the
case with two servers choosing the same port), but I still got:
16/53 postgresql:ssl / ssl/001_ssltests_36 OK 15.25s 205
subtests passed
17/53 postgresql:ssl / ssl/001_ssltests_30 ERROR 3.17s (exit
status 255 or signal 127 SIGinvalid)
2024-06-05 19:40:37.395 UTC [414110] LOG: starting PostgreSQL
17beta1 on x86_64-linux, compiled by gcc-13.2.1, 64-bit
2024-06-05 19:40:37.395 UTC [414110] LOG: could not bind IPv4
address "127.0.0.1": Address already in use
2024-06-05 19:40:37.395 UTC [414110] HINT: Is another postmaster
already running on port 50072? If not, wait a few seconds and retry.
`grep '\b50072\b' -r testrun/` yields:
testrun/ssl/001_ssltests_34/log/001_ssltests_34_primary.log:2024-06-05
19:40:37.392 UTC [414111] [unknown] LOG: connection received:
host=localhost port=50072
(a psql case)
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)
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.
Except that I see this on my Ubuntu instance:
$ sudo sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
And indeed I see client sockets in that range.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
