序列化例外：还有谁参与？

当作为SERIALIZABLE隔离级别的事务失败时，是否有办法知道哪个连接（即事务）涉及整个流程？序列化例外：还有谁参与？

我正在处理会计数据库。我知道我们应该重试交易，这就是我们所做的。我遇到了一个问题，即事务必须在繁忙的系统上运行10次才能成功。

这里应该有一个严重的问题。我想知道是否有一个配置参数允许系统在异常详细信息中告诉失败中涉及的其他连接。

关于SSI的Postgresql维基没有这种信息。

非常感谢。

编辑1：

我推日志DEBUG5水平没有运气。

所以我决定看看代码。序列化冲突检测在src/backend/storage/lmgr/predicate.c中完成，其中注定要失败的事务标记为SXACT_FLAG_DOOMED标志。

我只是添加elog（...）调用与DEBUG1级别，编译代码并试一试。

这是有趣的，因为现在它显示我是这样的：

2014-11-28 09:52:47 CET [9888]: [1-1] db=postgres,user=postgres DEBUG: 00000: 
SERIALIZABLE TX on Connection [12864] is marked DOOMED by SERIALIZABLE TX on Connection [9888]

现在我有积木明白发生了什么事情。

来源

2014-11-24 Olivier MATROT

在解决了这个问题之后，您应该考虑将编辑作为答案编写，无论现在还是之后。 SO社区可能会发现您在故障排除中添加的代码非常有用。这对PostgreSQL本身也可能是一个有用的贡献，可能作为一个新的日志记录选项。 – 2014-11-28 09:09:59

我会尽快做到这一点。 – 2014-11-28 12:45:47

您可以在PostgreSQL黑客名单中关注此主题的讨论：http://www.postgresql.org/message-id/[email protected] – 2014-12-02 14:38:21

首先看PostgreSQL的主日志文件。在我的盒子里，它在/ var/log/postgresql下。

之后，有一个lot of options用于记录和错误报告。您可以记录连接尝试，并且可以记录每个SQL语句。你应该能够把服务器的功能放在一起。

我想你应该阅读大部分链接的文档。某些选项对服务器吞吐量有重大影响。

来源

2014-11-24 13:13:29

我会尝试查看日志记录选项，重现问题并回来报告我的发现。 – 2014-11-24 17:44:11

我将日志推送到了DEBUG5级别，希望它能让我看到一些有趣的事情。没有运气。 – 2014-11-28 08:57:49

序列化例外：还有谁参与？

回答

相关问题