Sql 为什么在pg_统计活动中查询空闲数月?

Sql 为什么在pg_统计活动中查询空闲数月?,sql,database,postgresql,Sql,Database,Postgresql,我想更改一个名为order的表,但它被阻止了。然后我在pg_统计活动中发现了一些奇怪的东西: 这个查询闲置了3个月,我检查了24349进程是否存在。我发现删除成功了 那么,为什么这个问题持续了这么长时间?如何复制它?是虫子吗? 它是否阻塞了该表上的ddl?如果会话空闲,您看到的查询就是它执行的最后一个查询。如果当前未执行,则状态将处于活动状态。但是空闲的会话不应该阻塞alter表。你确定是那个会话阻塞了你的DDL吗?事务中空闲的会话可以做到这一点,但不是空闲的会话idle@a_horse_wit

我想更改一个名为order的表,但它被阻止了。然后我在pg_统计活动中发现了一些奇怪的东西:

这个查询闲置了3个月,我检查了24349进程是否存在。我发现删除成功了

那么,为什么这个问题持续了这么长时间?如何复制它?是虫子吗?
它是否阻塞了该表上的ddl?

如果会话空闲,您看到的查询就是它执行的最后一个查询。如果当前未执行,则状态将处于活动状态。但是空闲的会话不应该阻塞alter表。你确定是那个会话阻塞了你的DDL吗?事务中空闲的会话可以做到这一点,但不是空闲的会话idle@a_horse_with_no_name我知道你的意思。但我认为没有任何一次会议能持续3个月。客户端ip是172.17.0.1,我认为它是我们的应用程序docker容器之一。但是最长期的容器在它的开发环境中只持续六天。会话持续多长并不重要,它将持续到断开连接为止。这很正常。空闲会话无法阻止-仅在事务中空闲或明显处于活动状态
ss> select *  from pg_stat_activity where datname = 'ss' and query ilike 'delete%order%'
-[ RECORD 0 ]-------------------------
datid            | 80874
datname          | ss
pid              | 24349
usesysid         | 16384
usename          | user
application_name |
client_addr      | 172.17.0.1
client_hostname  | <null>
client_port      | 54008
backend_start    | 2017-09-26 09:36:46.928444+08
xact_start       | <null>
query_start      | 2017-09-26 10:29:26.337025+08
state_change     | 2017-09-26 10:29:26.352698+08
waiting          | False
state            | idle
backend_xid      | <null>
backend_xmin     | <null>
query            | DELETE FROM order WHERE order_id = '20180948464423'