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
>

Reply via email to