主页 / dba / 问题 / 315346
Accepted
Slim
Asked: 2022-08-08 23:29:49 +0800 CST

如何自动回滚事务？

  • 772

如何在例如 10 秒后自动回滚每个事务？

此参数是否有效？ idle_in_transaction_session_timeout

它看起来不错，但它只会杀死空闲会话。如果它们太长，是否可以杀死活跃的事务？如果是，我该怎么做？

上下文是避免死锁，停止重载，带来稳定性等。当然，这是DB的“最后机会”证券化。它并不能取代所有好的实践，比如查看查询计划、设计索引、约束和事务内容等......

编辑：全局自动事务回滚不是一个好主意。我计划在客户端本身内部为长时间迁移事务插入超时应用程序端。

postgresql postgresql-performance

2 个回答

  1. Best Answer

    如果它们太长，是否可以杀死活跃的事务？

    事务长时间运行只是一个症状，而不是真正问题的根本原因。最好找出为什么交易需要这么长时间并解决这个问题。此外，如果您的用户的工作被“计算机”“随机”杀死
    ，这对您的用户来说会非常非常烦人- 预计会有很多投诉。

    一个类比：如果 MS Word（或您使用的任何文字处理器）随机关闭（没有自动保存您的更改），您会如何“感觉”？你很快就会对它感到非常恼火。

    上下文是避免死锁，停止重载，带来稳定性等。

    • “死锁”：完全不同的野兽。
      当一个事务更新 A 然后想要更新 B 并且另一个事务已经更新 B 现在想要更新 A。两个事务将永远等待另一个完成，因此 DBMS 选择一个并将其杀死。
      [通常]数据库对此无能为力- 它[通常] 需要更改应用程序代码来解决它。
    • “重载”：
      杀死事务实际上可能会使事情变得更糟，因为当你杀死一个事务时，它之前完成的所有事情都必须回滚，而且通常情况下，这将优先于数据库正在尝试的所有其他事情去做。（我曾经不得不终止一个运行了 8 多个小时的 Oracle 事务——整个数据库在回滚发生时锁定了 20 分钟）。
    • 《稳定》：
      认真的？更改被“随机”杀死，用户不得不重做工作，整个数据库运行缓慢，因为正在发生的“随机”回滚......你会称之为“稳定”吗？

    ...这是 DB 的“最后机会”证券化。

    恕我直言，这不是一个“保护”您的数据库的现实的、长期的提议。

    找到并解决真正的问题。

    • 3

  2. 所以整个迁移将中止并且不会自动重试，然后您在下班时间或调查问题后再次尝试？我并没有真正把它当作一个好主意来卖，但在迁移中这样做肯定比在全局环境中这样做更合理。

    statement_timeout 是您想要的设置。一旦语句超时，它会抛出一个错误，整个事务将自动回滚。超时整个迁移可能更有意义，而不是每个单独的步骤。但我认为没有任何设置可以做到这一点。如果迁移是一个 shell 脚本，也许你可以安排 shell 处理取消。

    • 0

相关问题