我在我的应用程序代码中发现了一个错误,我已经启动了一个事务,但从未提交或执行回滚.连接是定期使用的,只需每10秒左右读取一些数据.在pg_stat_activity表中,其状态报告为“在事务中空闲”,其backend_start时间超过一周.
这对数据库有什么影响？它是否会导致额外的cpu和RAM使用？它会影响其他连接吗？在这种状态下它能持续多久？
我正在使用postgresql 9.1和9.4.
由于您只选择SELECT,因此影响有限.对于任何写入操作来说,它更严重,其中更改在提交之前对任何其他事务都不可见 – 如果从未提交则丢失.
它确实占用了一些RAM,并永久占用了您允许的连接之一(可能或不重要).
非常长时间运行的事务的一个更严重的后果：它阻止VACUUM执行它的工作,因为仍然有一个旧事务可以看到旧行.系统将开始膨胀.
特别是,SELECT在所有引用的表上获取了一个ACCESS SHARE锁(所有的阻塞最少).这不会干扰其他DML命令,如INSERT,UPDATE或DELETE,但它会阻止DDL命令以及TRUNCATE或VACUUM(包括autovacuum作业). See “Table-level Locks” in the manual.
它还可以干扰各种复制解决方案,并且如果它保持打开足够长时间/你足够快地刻录足够的XID,则可以长期导致事务ID环绕.更多关于in the manual on “Routine Vacuuming”.
如果阻止其他事务提交并且已经获得了自己的锁定,则阻塞效应可能会增加.等等.
您可以(几乎)无限期地保持事务处理 – 直到连接关闭(显然,当服务器重新启动时也会发生这种情况).但永远不要让交易开放时间超过需要.
