小编And*_*lov的帖子

互联网上有一些消息来源坚称idle in transaction连接可能会阻止真空清理死元组，以下是一些示例：

极光用户指南：

\n

处于空闲事务状态的事务可以持有阻止其他查询的锁。它还可以防止 VACUUM（包括 autovacuum）清理死行，从而导致索引或表膨胀或事务 ID 环绕。

\n

Cyber​​tec 博客

\n

长事务实际上不是问题 \xe2\x80\x93 如果必须存在长事务和许多小更改，问题就会开始。请记住：长事务可能会导致 VACUUM 无法清除死行。

\n

实际上，有很多，但从我的角度来看，这听起来绝对荒谬：在大多数情况下，事务隔离级别是读已提交，这反过来意味着不需要为此类事务保留死元组，而且，我找到了替代方案关于该主题的意见：

\n

它并不是真正的长期事务，而是长期快照。当然，长时间运行的 select 或 insert 语句可以做到这一点。对于高于读提交的隔离级别，整个事务将保留快照直到其宕机，因此如果某些事务打开了一个可重复读事务，然后在没有提交的情况下休假，那将是一个问题。挂起的准备好的交易也会（如果您不知道什么是准备好的交易，那么您可能没有使用它们）。

\n

或Pavel Luzanov 在 Cyber​​tec 博文下的评论：

\n

我相信长事务的示例仅适用于可重复读取（或可序列化）隔离级别。但默认情况下 BEGIN 使用已提交读。因此，在第一个会话中的 SELECT 完成后，VACUUM 将在会话 2 中的后续 UPDATE、DELETE 命令之后删除表中的死行。

\n

@Bill Karwin在他的回答中实际上证实了这一点（谢谢！）

问题是：是否存在“有效”“非虚构”场景时idle in transaction …