postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier

Hi,

I amd working on adding an "installcheck" equivalent mode to the meson
build. One invocation of something "installcheck-world" like lead to things
getting stuck.

Lots of log messages like:

2022-09-25 16:16:30.999 PDT [2705454][client backend][28/1112:41269][pg_regress] LOG: still waiting for backend with PID 2705178 to accept ProcSignalBarrier
2022-09-25 16:16:30.999 PDT [2705454][client backend][28/1112:41269][pg_regress] STATEMENT: DROP DATABASE IF EXISTS "regression_test_parser_regress"
2022-09-25 16:16:31.006 PDT [2705472][client backend][22/3699:41294][pg_regress] LOG: still waiting for backend with PID 2705178 to accept ProcSignalBarrier
2022-09-25 16:16:31.006 PDT [2705472][client backend][22/3699:41294][pg_regress] STATEMENT: DROP DATABASE IF EXISTS "regression_test_predtest_regress"

a stacktrace of 2705178 shows:

(gdb) bt
#0 0x00007f67d26fe1b3 in __GI___poll (fds=fds(at)entry=0x7ffebe187c88, nfds=nfds(at)entry=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f67cfd03c1c in pqSocketPoll (sock=<optimized out>, forRead=forRead(at)entry=1, forWrite=forWrite(at)entry=0, end_time=end_time(at)entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:1125
#2 0x00007f67cfd04310 in pqSocketCheck (conn=conn(at)entry=0x562f875a9b70, forRead=forRead(at)entry=1, forWrite=forWrite(at)entry=0, end_time=end_time(at)entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:1066
#3 0x00007f67cfd043fd in pqWaitTimed (forRead=forRead(at)entry=1, forWrite=forWrite(at)entry=0, conn=conn(at)entry=0x562f875a9b70, finish_time=finish_time(at)entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:998
#4 0x00007f67cfcfc47b in connectDBComplete (conn=conn(at)entry=0x562f875a9b70) at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-connect.c:2166
#5 0x00007f67cfcfe248 in PQconnectdbParams (keywords=keywords(at)entry=0x562f87613d20, values=values(at)entry=0x562f87613d70, expand_dbname=expand_dbname(at)entry=0)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-connect.c:659
#6 0x00007f67cfd29536 in connect_pg_server (server=server(at)entry=0x562f876139b0, user=user(at)entry=0x562f87613980)
at ../../../../home/andres/src/postgresql/contrib/postgres_fdw/connection.c:474
#7 0x00007f67cfd29910 in make_new_connection (entry=entry(at)entry=0x562f8758b2c8, user=user(at)entry=0x562f87613980)
at ../../../../home/andres/src/postgresql/contrib/postgres_fdw/connection.c:344
#8 0x00007f67cfd29da0 in GetConnection (user=0x562f87613980, will_prep_stmt=will_prep_stmt(at)entry=false, state=state(at)entry=0x562f876136a0)
at ../../../../home/andres/src/postgresql/contrib/postgres_fdw/connection.c:204
#9 0x00007f67cfd35294 in postgresBeginForeignScan (node=0x562f87612e70, eflags=<optimized out>)

and it turns out that backend can't be graciously be terminated.

Maybe I am missing something, but I don't think it's OK for
connect_pg_server() to connect in a blocking manner, without accepting
interrupts?

Greetings,

Andres Freund