使用PHP的pg_ *函数时如何检测PostgreSQL中的死锁？

我在PostgreSQL中使用事务。事务是严肃的数据库基础的必要组成部分。交易不可避免地导致“僵局”。死锁将按原样记录为错误。我不想记录任何错误，所以我需要处理这些死锁。据称，死锁是通过检测到它们，抑制错误并重试查询直到没有死锁的方式来处理的。

到目前为止，很好。

现在开始问题。我使用pg_query_params()和pg_query()将查询发送到PostgreSQL。两者均在失败时返回FALSE，或在成功时返回“查询结果资源”。当PostgreSQL检测到死锁时，这些函数将返回FALSE，而我的PHP错误日志中会出现关于死锁的大量噪音。

PHP手册对pg_last_error()进行了说明：

错误消息可能会被内部PostgreSQL（libpq）函数调用覆盖。如果PostgreSQL模块函数内部发生多个错误，它可能不会返回适当的错误消息。

因此不可靠，无法使用。它继续说明：

使用pg_result_error（），pg_result_error_field（），pg_result_status（）和pg_connection_status（）可以更好地处理错误。

查找了这些功能后，我惊骇地意识到（如它所说）：

由于如果查询失败，pg_query（）返回FALSE，则必须使用pg_send_query（）和pg_get_result（）来获取结果句柄。

pg_send_query()和pg_send_query_params()则是异步。我既不需要也不了解这种“异步” SQL查询。我不知道这是怎么可能的，或者为什么有人会想要它。

最终结果是，我再次发现自己被涂在一个角落里，看来唯一的出路是在烟囱里爬行，让自己变得肮脏而凌乱。

看来我被迫完全放弃pg_query_params()和pg_query()只是为了能够检测死锁。真的可以吗？我只能想象，“异步”发送SQL查询会产生什么新错误，而不是有序地“阻塞”发送。

为什么总是这样？每当我尝试做任何事情时，无论多么基础或普遍，对于其他所有人来说，它似乎总是被视为“奇怪的情况”。当然，除了使用我直到昨天才听说过的这些奇怪的“异步”功能破坏我的整个应用程序的完整性之外，肯定还有其他方法可以检测到死锁吗？

即使我要使用它们，也仍然不清楚如何准确地检测到死锁。他们是否希望我解析错误并查找诸如“ deadlock ”之类的英语字符串？这似乎也不是完全正确。感觉像个奇怪的骇客。

真的没有正确，干净的方法来检测死锁，以便可以正确处理死锁吗？

简单地抑制PHP错误（通过使用自定义错误记录器并检查字符串）只会解决错误日志噪音的问题，但实际上并不会使死锁的查询重试，因此它们将永远不会做自己的工作，并且只是被默默忽略。

如果有人在乎，我最终以阻塞的方式“滥用” pg_send_*查询，只是为了能够正确地抓住死锁（以及将来可能发生的其他错误）。这是唯一的解决方案，尽管它使我对解决方案感到满意而不是满意。也许看到这种自我回答将有助于将来的人们意识到尝试其他方法完全浪费时间，因为我做了很长时间，但失败了。