postgresql – 不结束数据库事务有什么后果？
发布时间：2020-12-13 16:34:21 所属栏目：百科 来源：网络整理
导读：我在我的应用程序代码中发现了一个错误,我已经启动了一个事务,但从未提交或执行回滚.连接是定期使用的,只需每10秒左右读取一些数据.在pg_stat_activity表中,其状态报告为“在事务中空闲”,其backend_start时间超过一周. 这对数据库有什么影响？它是否会导致
|
我在我的应用程序代码中发现了一个错误,我已经启动了一个事务,但从未提交或执行回滚.连接是定期使用的,只需每10秒左右读取一些数据.在pg_stat_activity表中,其状态报告为“在事务中空闲”,其backend_start时间超过一周.
这对数据库有什么影响？它是否会导致额外的CPU和RAM使用？它会影响其他连接吗？在这种状态下它能持续多久？ 我正在使用postgresql 9.1和9.4.
由于您只选择SELECT,因此影响有限.对于任何写入操作来说,它更严重,其中更改在提交之前对任何其他事务都不可见 – 如果从未提交则丢失.
它确实占用了一些RAM,并永久占用了您允许的连接之一(可能或不重要). 非常长时间运行的事务的一个更严重的后果：它阻止 特别是,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”. 如果阻止其他事务提交并且已经获得了自己的锁定,则阻塞效应可能会增加.等等. 您可以(几乎)无限期地保持事务处理 – 直到连接关闭(显然,当服务器重新启动时也会发生这种情况).但永远不要让交易开放时间超过需要. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |