From: Tom Lane <tgl@sss.pgh.pa.us>
To: Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: PostgreSQL 16.6 , query stuck with STAT Ssl,
 wait_event_type : IPC , wait_event : ParallelFinish
In-reply-to: <c78f4a69-eeb6-49b2-8b95-d232b457d6fc@cloud.gatewaynet.com>
References: <c1d1e271-9a71-4469-85da-da168fc6440e@cloud.gatewaynet.com>
 <c78f4a69-eeb6-49b2-8b95-d232b457d6fc@cloud.gatewaynet.com>
Comments: In-reply-to Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>
	message dated "Sun, 01 Jun 2025 00:12:50 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3049793.1748751598.1@sss.pgh.pa.us>
Date: Sun, 01 Jun 2025 00:19:58 -0400
Message-ID: <3049794.1748751598@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3049794.1748751598%40sss.pgh.pa.us>
Precedence: bulk

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