1

在使用 Postgres 的 Django 1.3 项目中，我有一个“DatabaseError：current transaction is aborted”来来去去（具体来说，841 次中有 11 次）。该项目是一个测验网站，当用户在视图中提交答案表单时会发生错误。从数据库的角度来看，该过程涉及许多查询，如下所示：

  1. 收集问题的所有正确答案（它们是多项选择，可能需要多个答案）*
  2. 抓取用户的个人资料
  3. 保存此答案
  4. 查询用户的新积分总数
  5. 将总数保存到他们的个人资料中
  6. 检查他们是否有资格获得新的奖励
  7. 如果他们这样做了，就奖励新的奖励

在那个受折磨的过程中的某个地方，这个错误突然出现（我猜是因为一个查询没有等待其他查询）。有没有办法让我在生产中（即 DEBUG = False）在这种情况下记录数据库错误？我在 WebFaction 上，我无法使用 Postgres 错误日志。我可以从这个中间件示例中窃取一些东西来在这种特定情况下触发吗？

或者，是否有更好的方法来查找此错误，或者我应该将单个查询包装在事务中（不幸的是，它们不在代码中的相同位置，不确定将视图包装在事务装饰器中是否会有所帮助）？

*只是为了混淆问题，在开发过程中添加了多个正确答案的要求，然后在我们上线之前就放弃了，所以我可以稍微简化这个过程，基本上跳过步骤 1 和 4，但我想知道一个这类神秘问题的一般答案。

4

2 回答 2

1

您必须为事务启用自动提交。在您的DATABASES条目中，包括：

'OPTIONS': {'autocommit': True,},

默认情况下，Django 在第一次查询时打开一个事务。通过使用此选项，您必须手动启动事务（例如使用@commit_on_success）。由于不再有交易打开，您将得到之前被交易错误掩盖的实际错误。

自动提交设置将是 Django 1.6 的新默认设置，请参阅https://docs.djangoproject.com/en/dev/ref/databases/#postgresql-notes

于 2013-05-02T09:56:42.427 回答
1

你还没有说在你的 7 个步骤中你有交易的开始和结束。知道这会很有帮助。

“事务中止”消息的一种来源是由于死锁。更多详细信息将在 PostgreSQL 日志中。

但最重要的是，如果您无法访问 PostgreSQL 错误消息，您将继续在调试 PostgreSQL 时遇到痛苦且耗时的经历。使用 WebFaction 来解决这个问题。如果它们不能提供帮助并且您的时间很有价值，那么通过迁移到提供此基本功能的环境，您的底线成本将会降低。

于 2012-08-02T15:45:09.597 回答