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

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