postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
| От | Andres Freund |
|---|---|
| Тема | postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier |
| Дата | |
| Msg-id | 20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de обсуждение исходный текст |
| Ответы |
Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier |
| Список | pgsql-hackers |
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
PID2705178 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
PID2705178 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@entry=0x7ffebe187c88, nfds=nfds@entry=1, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f67cfd03c1c in pqSocketPoll (sock=<optimized out>, forRead=forRead@entry=1, forWrite=forWrite@entry=0,
end_time=end_time@entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:1125
#2 0x00007f67cfd04310 in pqSocketCheck (conn=conn@entry=0x562f875a9b70, forRead=forRead@entry=1,
forWrite=forWrite@entry=0,end_time=end_time@entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:1066
#3 0x00007f67cfd043fd in pqWaitTimed (forRead=forRead@entry=1, forWrite=forWrite@entry=0,
conn=conn@entry=0x562f875a9b70,finish_time=finish_time@entry=-1)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-misc.c:998
#4 0x00007f67cfcfc47b in connectDBComplete (conn=conn@entry=0x562f875a9b70) at
../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-connect.c:2166
#5 0x00007f67cfcfe248 in PQconnectdbParams (keywords=keywords@entry=0x562f87613d20,
values=values@entry=0x562f87613d70,expand_dbname=expand_dbname@entry=0)
at ../../../../home/andres/src/postgresql/src/interfaces/libpq/fe-connect.c:659
#6 0x00007f67cfd29536 in connect_pg_server (server=server@entry=0x562f876139b0, user=user@entry=0x562f87613980)
at ../../../../home/andres/src/postgresql/contrib/postgres_fdw/connection.c:474
#7 0x00007f67cfd29910 in make_new_connection (entry=entry@entry=0x562f8758b2c8, user=user@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@entry=false,
state=state@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
В списке pgsql-hackers по дате отправления: