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
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... |