“检测到死锁”真的是一个错误吗？处理完之后我应该压制他们吗？

Question

不久前，我花了噩梦般的几周时间来处理“检测到死锁”并试图找出如何处理它。我最终以这样的方式处理它：我的代码能够检测到它何时发生，然后无限期地重试相同的查询，每次重试之间间隔 50000 微秒，直到它起作用。

也许这是不好的做法，但到​​目前为止（几个月），除了记录“检测到死锁”所谓的“错误”之外，它还没有引起任何问题。

我现在可以通过将“检测到死锁”错误标记为“不重要”来抑制它们，从而不会向我显示，即使它们仍然记录到我的错误日志表中，这是否“可以”？

请不要告诉我“首先避免它们”。这根本不可能。如果您在同一个表/事物上并发（多个进程/脚本实例）工作，它们显然会发生。我花了很长时间试图“将它们编码掉”，但这似乎是不可能的。

显然，因为我问这个问题而不是仅仅添加忽略规则并完成它，所以我确实关心答案/响应。尽管如此，我认为目前还不能确信它们可以完全避免。我并不是说我每小时都会记录数千个记录，而是每天都会记录一些记录，似乎总是在一开始，当我确实有很多并发进程在同一个表/查询上工作时。

Answer 1

死锁是一种序列化错误：您没有执行任何禁止的操作，只是碰巧与其他活动事务进行了交互，从而阻止了您的事务完成。您的反应是正确的：重试交易。完全无需等待即可重试。

我同意，由于较大事务的工作量足够复杂，因此几乎不可能完全排除死锁。只要它们很少发生，只要您正确处理它们，它们就不是真正的问题。

如果死锁发生得太频繁，那么死锁就会成为一个问题：这意味着您必须重做大量工作，这不仅会降低性能，还会给数据库带来额外的负载。另外，死锁解决前的一秒等待意味着锁被持有很长时间（一秒很长），这对于并发来说并不是很好。

即使无法完全摆脱死锁，也可以采取措施来减少死锁：

• 看到您的交易时间很短

• 尝试减少每个事务的数据修改次数

两者都会减少陷入僵局的可能性。

忽略日志文件中的死锁错误是安全的，但是您应该监视pg_stat_database.deadlocks每小时死锁计数超出可接受数量的情况并采取措施。

您看到反对将死锁称为错误。根据定义，错误是中止 SQL 语句执行的条件。所以死锁显然是一个错误。