Thread: PostgreSQL 16.6 , query stuck with STAT Ssl, wait_event_type : IPC , wait_event : ParallelFinish

Hi

a query is stuck with the above, it seems it waits for parallel worker to finish, however , there are no parallel works running :

postgres@[local]/dynacom=# SELECT application_name, backend_type, backend_start,xact_start,query_start,wait_event_type, wait_event ,state FROM pg_stat_activity;
application_name |         backend_type         |         backend_start         |          xact_start           |          query_start          | wait_event_type |     wait_event      | state   
------------------+------------------------------+-------------------------------+-------------------------------+-------------------------------+-----------------+---------------------+--------
                 | autovacuum launcher          | 2024-11-29 17:48:50.92935+02  |                               |                               | Activity        | AutoVacuumMain      |  
                 | logical replication launcher | 2024-11-29 17:48:50.929496+02 |                               |                               | Activity        | LogicalLauncherMain |  
DBMIRROR         | client backend               | 2025-05-31 19:04:16.724305+03 | 2025-05-31 19:05:21.686093+03 | 2025-05-31 19:05:21.909936+03 | IPC             | ParallelFinish      | active
                 | client backend               | 2025-05-31 23:31:30.030806+03 |                               | 2025-05-31 23:35:05.045573+03 | Client          | ClientRead          | idle
psql             | client backend               | 2025-05-31 23:29:33.863485+03 | 2025-05-31 23:35:09.322972+03 | 2025-05-31 23:35:09.322972+03 |                 |                     | active
RXMLFVSLS        | client backend               | 2025-05-31 23:32:37.351131+03 |                               | 2025-05-31 23:35:09.295221+03 | Client          | ClientRead          | idle
psql             | client backend               | 2025-04-28 16:59:55.968442+03 |                               | 2025-05-27 16:43:56.338228+03 | Client          | ClientRead          | idle
                 | background writer            | 2024-11-29 17:48:50.916876+02 |                               |                               | Activity        | BgWriterMain        |  
                 | archiver                     | 2024-12-03 18:57:36.447067+02 |                               |                               | Activity        | ArchiverMain        |  
                 | checkpointer                 | 2024-11-29 17:48:50.916648+02 |                               |                               | Activity        | CheckpointerMain    |  
                 | walwriter                    | 2024-11-29 17:48:50.928789+02 |                               |                               | Activity        | WalWriterMain       |  
(11 rows)

postgres@[local]/dynacom=#

So, I will terminate this backend now to get the system working again, we are curious why this happened, our system serves daily 22M+ transactions, this is Saturday night hence the low traffic.

postgres@smadb:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm
postgres@smadb:~$ psql -Aqt -c 'select version()'
PostgreSQL 16.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
postgres@smadb:~$

Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> writes:
>> a query is stuck with the above, it seems it waits for parallel worker 
>> to finish, however , there are no parallel works running :

You didn't explain the subject about "STAT Ssl", but if you mean
that that was what ps was showing for the backend process, there's
something very wrong there.  According to "man ps", the "l" means

               l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads
                    do)

which is something that a Postgres backend should never be
(in existing releases anyway).  So I'm speculating that
the process somehow became multi-threaded and then some
wakeup signal went to the wrong thread.

We've had issues with perl or python introducing multi-threading
because of plperl or plpython functions doing things they
probably shouldn't.  Do you have any of those in your system?

            regards, tom lane