Sporadic connection-setup-related test failures on Cygwin in v15- - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Sporadic connection-setup-related test failures on Cygwin in v15-
Date
Msg-id 26fa3a71-7727-8a5f-1af5-1b842e8ffeac@gmail.com
Whole thread Raw
Responses Re: Sporadic connection-setup-related test failures on Cygwin in v15-
List pgsql-hackers
Hello hackers,

A recent lorikeet (a Cygwin animal) failure [1] revealed one more
long-standing (see also [2], [3], [4]) issue related to Cygwin:
  SELECT dblink_connect('dtest1', connection_parameters());
- dblink_connect
-----------------
- OK
-(1 row)
-
+ERROR:  could not establish connection
+DETAIL:  could not connect to server: Connection refused

where inst/logfile contains:
2024-07-16 05:38:21.492 EDT [66963f67.7823:4] LOG:  could not accept new connection: Software caused connection abort
2024-07-16 05:38:21.492 EDT [66963f8c.79e5:170] pg_regress/dblink ERROR:  could not establish connection
2024-07-16 05:38:21.492 EDT [66963f8c.79e5:171] pg_regress/dblink DETAIL:  could not connect to server: Connection
refused
         Is the server running locally and accepting
         connections on Unix domain socket "/home/andrew/bf/root/tmp/buildfarm-DK1yh4/.s.PGSQL.5838"?

I made a standalone reproducing script (assuming the dblink extension
installed):
numclients=50
for ((i=1;i<=1000;i++)); do
echo "iteration $i"

for ((c=1;c<=numclients;c++)); do
cat << 'EOF' | /usr/local/pgsql/bin/psql >/dev/null 2>&1 &

SELECT 'dbname='|| current_database()||' port='||current_setting('port')
   AS connstr
\gset

SELECT * FROM dblink('service=no_service', 'SELECT 1') AS t(i int);

SELECT * FROM
dblink(:'connstr', 'SELECT 1') AS t1(i int),
dblink(:'connstr', 'SELECT 2') AS t2(i int),
dblink(:'connstr', 'SELECT 3') AS t3(i int),
dblink(:'connstr', 'SELECT 4') AS t4(i int),
dblink(:'connstr', 'SELECT 5') AS t5(i int);
EOF
done
wait

grep -A1 "Software caused connection abort" server.log && break;
done

which fails for me as below:
iteration 318
2024-07-24 04:19:46.511 PDT [29062:6][postmaster][:0] LOG:  could not accept new connection: Software caused connection

abort
2024-07-24 04:19:46.512 PDT [25312:8][client backend][36/1996:0] ERROR:  could not establish connection

The important fact here is that this failure is not reproduced after
7389aad63 (in v16), so it seems that it's somehow related to signal
processing. Given that, I'm inclined to stop here, without digging deeper,
at least until there are plans to backport that fix or something...

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2024-07-16%2009%3A18%3A31 (REL_13_STABLE)
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2022-07-21%2000%3A36%3A44 (REL_14_STABLE)
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2023-07-06%2009%3A19%3A36 (REL_12_STABLE)
[4] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2022-02-12%2001%3A40%3A56 (REL_13_STABLE, 
postgres_fdw)

Best regards,
Alexander



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Interrupts vs signals
Next
From: Noah Misch
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)