Wow, 9 days is a long time. The fact that it is not responding to
pg_terminate_backend means it's not even calling CHECK_FOR_INTERRUPTS
inside the WaitForParallelWorkersToFinish loop, so something is seriously
wrong. If the PID is still there, please do what Laurenz suggested:
strace -tp 356274
I
pgsql 17.5 on Red Hat Enterprise Linux release 8.10 (Ootpa)
The query is run from one of our php applications.
On Fri, Nov 7, 2025 at 8:59 PM Laurenz Albe
wrote:
> On Fri, 2025-11-07 at 19:18 +0530, Ashish Mukherjee wrote:
> > I have a query like this showing up on my production database -
> >
On 11/7/25 05:48, Ashish Mukherjee wrote:
Hello,
I have a query like this showing up on my production database -
The query when run from psql prompt finishes in a jiffy, so query
What client is the stuck query being run from?
Regards,
Ashish
--
Adrian Klaver
[email protected]
On Fri, 2025-11-07 at 19:18 +0530, Ashish Mukherjee wrote:
> I have a query like this showing up on my production database -
>
> s05=> SELECT pid, user, usename, application_name, client_addr,
> client_hostname, client_port, datname, now() - query_start as "runtime",
> state, wait_event_type, wa
On Fri, Nov 7, 2025 at 8:49 AM Ashish Mukherjee
wrote:
> Hello,
>
> I have a query like this showing up on my production database -
>
> s05=> SELECT pid, user, usename, application_name, client_addr,
> client_hostname, client_port, datname, now() - query_start as "runtime",
> state, wait_event_ty
Hello,
I have a query like this showing up on my production database -
s05=> SELECT pid, user, usename, application_name, client_addr,
client_hostname, client_port, datname, now() - query_start as "runtime",
state, wait_event_type, wait_event,
substr(query, 0, 100)
FROM pg_stat_activity
WHERE
