Re: EXPLAIN <query> command just hangs...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rhhh Lin <ruanlinehan(at)hotmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: EXPLAIN <query> command just hangs...
Date: 2017-11-04 16:35:25
Message-ID: 8962.1509813325@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Rhhh Lin <ruanlinehan(at)hotmail(dot)com> writes:
> So I decided to intervene and terminate some active sessions (Which were active and not waiting) which were all querying this table with a similar query, by using pg_backend_terminate(pid). Some of these sessions were in an active state for a few days executing this query. However, the termination of the PIDs [The command succeeded and returned 't']has not closed down the sessions. They are still present, and still active and still executing. Those current sessions are for whatever reason completely "hung", locking out exclusive access to the table (from vacuum) and cannot be killed. I have not yet resorted to trying to kill the process PID's from the OS perspective. Instead, I will try to schedule an outage over the next few days, restart the server, implement a vacuum execution and see where I am at then.

Well, that's pretty interesting in itself. Any chance of attaching to one
of those unkillable backends with gdb and getting a stack trace?

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Marc-Olaf Jaschke 2017-11-04 16:41:38 A possible use case for: "INSERT .. ON CONFLICT DO SELECT [FOR ..]"
Previous Message Rhhh Lin 2017-11-04 02:29:05 Re: EXPLAIN <query> command just hangs...