Sorry, wrong stack trace. Here is a correct one:
(gdb) bt
#0 0x7f9acca1bdf6 in do_futex_wait.constprop () from
/lib64/libpthread.so.0
#1 0x7f9acca1bee8 in __new_sem_wait_slow.constprop.0 () from
/lib64/libpthread.so.0
#2 0x007815a2 in PGSemaphoreLock ()
#3 0x007fca6c in LWLockAcquire ()
#4 0x7f9ac5c385e6 in pgsm_store () from
/usr/pgsql-15/lib/pg_stat_monitor.so
#5 0x7f9ac5c39a6b in pgsm_ExecutorEnd () from
/usr/pgsql-15/lib/pg_stat_monitor.so
#6 0x00658d91 in PortalCleanup ()
#7 0x0095b264 in PortalDrop ()
#8 0x0080c6df in exec_simple_query ()
#9 0x0080de22 in PostgresMain ()
#10 0x0078db80 in ServerLoop ()
#11 0x0078eb34 in PostmasterMain ()
#12 0x0050474d 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 wrote:
> Andrey Zhidenkov 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
>