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

From: Achilleas Mantzios <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>, itdev(at)gatewaynet(dot)com
Subject: Re: PostgreSQL 16.6 , query stuck with STAT Ssl, wait_event_type : IPC , wait_event : ParallelFinish
Date: 2025-06-01 05:32:06
Message-ID: 6be8d715-a9a7-4be8-8ebc-8b6bdb98da2e@cloud.gatewaynet.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 1/6/25 07:19, Tom Lane wrote:

> Achilleas Mantzios<a(dot)mantzios(at)cloud(dot)gatewaynet(dot)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)
Yes. sorry, I didn't include this info, you are spot on, yes this the
output of ps aux .
> 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?

Yes we have two perl functions only that I'd be happy to get rid off :

postgres(at)[local]/dynacom=# select p.proname, l.lanname from pg_language
l, pg_proc p where p.prolang=l.oid and l.lanname ~* '.*perl.*';
proname  | lanname
----------+---------
basename | plperlu
filetype | plperlu
(2 rows)

Nothing used in the app, just some two utility functions to help us
batch insert some attachments, guess mimetype etc. However the calling
client is Perl , based on libpg-perl (not DBI), basically this is a
descendant of DBMirror.pl (we are still using it).

The strange thing is that we run pgsql 16.* since November, also we run
our version of DBMirror since 2005 (and PostgreSQL since 2001) and we
never had this problem before (at least from what I know).

>
> regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Motog Plus 2025-06-02 12:55:32 Re: Seeking Suggestions for Best Practices: Archiving and Migrating Historical Data in PostgreSQL
Previous Message Tom Lane 2025-06-01 04:19:58 Re: PostgreSQL 16.6 , query stuck with STAT Ssl, wait_event_type : IPC , wait_event : ParallelFinish