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 ()
Andrey Zhidenkov <pensnarik@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