From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kaijiang Chen <chenkaijiang(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: weird long time query |
Date: | 2019-12-17 17:04:20 |
Message-ID: | 5019.1576602260@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general pgsql-performance |
Kaijiang Chen <chenkaijiang(at)gmail(dot)com> writes:
> I'm using postgres 9.4.17 on centos 7.
> I check the running queries with the following SQL:
> SELECT
> procpid,
> start,
> now() - start AS lap,
> current_query
> FROM
> (SELECT
> backendid,
> pg_stat_get_backend_pid(S.backendid) AS procpid,
> pg_stat_get_backend_activity_start(S.backendid) AS start,
> pg_stat_get_backend_activity(S.backendid) AS current_query
> FROM
> (SELECT pg_stat_get_backend_idset() AS backendid) AS S
> ) AS S
> WHERE
> current_query <> '<IDLE>'
> ORDER BY
> lap DESC;
Don't know where you got this query from, but it's wrong for any PG
version more recent than (I think) 9.1. We don't use "<IDLE>" as an
indicator of idle sessions anymore; rather, those can be identified
by having state = 'idle'. What's in the query column for such a session
is its last query.
> Then, I found a SQL that has run for some days (and still running):
> procpid | 32638
> start | 2019-11-25 16:29:29.529318+08
> lap | 21 days 18:24:54.707369
> current_query | DEALLOCATE pdo_stmt_00000388
It's not running. That was the last query it ran, back in November :-(
You could zap the session with pg_terminate_backend(), but
pg_cancel_backend() is not going to have any effect because there's
no active query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-12-17 17:26:07 | Re: BUG #16169: Default time output for 24:00 is 00:00 |
Previous Message | Tom Lane | 2019-12-17 16:31:34 | Re: Planning time is high in Postgres 11.5 Compared with Postgres 10.11 |
From | Date | Subject | |
---|---|---|---|
Next Message | George Neuner | 2019-12-17 20:06:58 | Re: Fast, stable, portable hash function producing 4-byte or 8-byte values? |
Previous Message | Steven Winfield | 2019-12-17 16:12:07 | Row locks, SKIP LOCKED, and transactions |
From | Date | Subject | |
---|---|---|---|
Next Message | Piotr Włodarczyk | 2019-12-17 20:03:41 | shared memory size during upgrade pgsql with partitions |
Previous Message | Jeff Janes | 2019-12-17 16:11:12 | Re: Consecutive Query Executions with Increasing Execution Time |