将我的Django 1.6应用程序升级到Django 1.7后，我从PostgreSQL获取数据时开始出现随机错误：
DatabaseError: server sent data ("D" message) without prior row description ("T" message)
lost synchronization with server: got message type "�", length -1244613424
DatabaseError: lost synchronization with server: got message type "0", length 842674226
ProgrammingError: no results to fetch
ValueError: invalid literal for int() with base 10: 'feuj3f47jvsdv7tgnj43g63j'
当我在浏览器中快速打开10个选项卡时，一半选项卡正常加载，其中一半会出现数据库错误。当我刷新发生错误的选项卡时，它们会正常加载。
我通过uwsgi和nginx运行Django，psycopg2的版本是2.5.4。
总体而言，看起来与Postgres的某些通信完全被破坏，不同查询的结果混合在一起。
编辑：
经过几个小时的故障排除后，我发现了以下内容：
Django 1.6 + uwsgi - 作品
Django 1.7 + gunicorn - 作品
Django 1.7 + uwsgi - 不起作用，抛出数据库错误。所以问题似乎与特定的uwsgi和Django 1.7组合。这很奇怪，我有另一个Django 1.7项目在同一台服务器上运行，具有相同的uwsgi，没有问题。
有什么想法吗？
（我真的不介意切换到gunicorn，可能不得不这样做，但它仍然很有趣，为什么会发生这种情况）
更新2：仔细检查显示Django内部发生了完全疯狂的事情，就像模型的主键被当前用户的session_id替换（这是“带有基数为10的int（）的无效文字”的来源）和Django发出查询DB“遗忘”指定WHERE子句。我可能会说某种内存损坏。
更新3：我们从uwsgi切换到gunicorn，问题现在已经消失。一切都很好。我可能仍在寻找合适的解决方案。
答案 0 :(得分：6)
我认为lazy-apps=true应该做到这一点。来自uwsgi文档：
uWSGI尽可能尝试（ab）使用fork（）调用的Copy On Write语义。默认情况下，它会在加载应用程序之后进行分叉，以尽可能多地共享内存。如果出于某种原因不希望出现此行为，请使用lazy-apps选项。这将指示uWSGI在每个worker的fork（）之后加载应用程序。请注意，有一个名为lazy的旧选项更具侵入性和高度劝阻（它仍然仅用于向后兼容）
如果你不打开lazy-apps，工作人员将共享内存，并且很可能会破坏它：
模型的主键被当前用户的session_id替换。
当涉及到连接和内容时，不设置lazy-apps是危险的。
缺点是每个工作人员都有一个完整的连接池（如果正在进行连接池），并且最终可能会使用大量连接。
我没有python专家，但我认为使用像gevent这样的东西来集中处理连接池。您甚至可能不需要lazy-apps。