Sorry, wrong stack trace. Here is a correct one: (gdb) bt #0 0x00007f9acca1bdf6 in do_futex_wait.constprop () from /lib64/libpthread.so.0 #1 0x00007f9acca1bee8 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00000000007815a2 in PGSemaphoreLock () #3 0x00000000007fca6c in LWLockAcquire () #4 0x00007f9ac5c385e6 in pgsm_store () from /usr/pgsql-15/lib/pg_stat_monitor.so #5 0x00007f9ac5c39a6b in pgsm_ExecutorEnd () from /usr/pgsql-15/lib/pg_stat_monitor.so #6 0x0000000000658d91 in PortalCleanup () #7 0x000000000095b264 in PortalDrop () #8 0x000000000080c6df in exec_simple_query () #9 0x000000000080de22 in PostgresMain () #10 0x000000000078db80 in ServerLoop () #11 0x000000000078eb34 in PostmasterMain () #12 0x000000000050474d in main ()
It’s seems to be a problem in pg_stat_monitor extension. The similar issue is described here (in Chinese): https://blog.csdn.net/qq_43687755/article/details/117592635 On Thu, 21 Dec 2023, 18:32 Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrey Zhidenkov <pensna...@gmail.com> writes: > > We have encountered an issue with our PostgreSQL 15.5 installation. The > > problem is that > > PostgreSQL server periodically falls into a state when it accepts new > > connections but > > doesn't execute any queries. The session which runs a query hangs and > > cannot be terminated > > via SIGINT (even if it's just "SELECT 1") - a corresponding linux process > > has state "S" and it's > > not terminated even if the PostgreSQL master process is stopped. No > matter > > how we connect to > > the database - both TCP and unix socket sessions hang but it seems that > > existing sessions can > > still execute queries (once we succeeded to connect using pgBouncer which > > seemed to use an > > existing connection to the database). > > Try using an existing session to capture pg_stat_activity and pg_locks > information about the stuck session(s). > > > Here is a stack trace from gdb for one of the frozen sessions: > > This appears to be a trace of a psql process waiting for a query > result. It won't teach you much about what the server is doing. > > regards, tom lane >