Postgres 8.4.4 + psycopg2 +蟒蛇 2.6.5 + Win7不稳定
您可以在问题标题中看到我正在使用的软件组件的组合。
我有一个简单的 10 表数据库在 Postgres 服务器（Win 7 Pro）上运行。我有客户端应用程序（Python 使用 psycopg 连接到 Postgres），它们以随机间隔连接到数据库以进行相对较轻的事务。一次只有一个客户端应用程序执行任何类型的繁重事务，并且这些事务通常<; 500 毫秒。其余的人花费更多的时间连接而不是实际等待数据库执行事务。关键是数据库处于轻负载状态，但负载在读取和写入之间平均分配。
我的客户端应用程序本身作为服务器/服务运行。我发现（1）完全关闭 Postgres 服务器，以及（2）通过键盘中断杀死客户端应用程序来破坏数据库对我来说是很常见的。
(1) 是指服务器上的 Postgres 进程中止并且需要重新启动服务。
通过（2），我的意思是，每当客户端在重新启动并（大概）完成“恢复模式”操作后尝试访问数据库时，数据库就会再次崩溃。我需要从数据库服务器中删除旧的数据库/架构，然后每次重建它以将其恢复到稳定状态。 （在恢复模式之后，我尝试了 Vacuum 的各种组合，看看是否可以提高稳定性；vacuum 运行，但当客户端尝试再次访问数据库时，服务器仍然会快速关闭。）
我不记得看到过相同的效果当我使用“taskkill”终止客户端应用程序时 - 仅当使用键盘中断来关闭 python 进程时。这种情况并不总是发生，但发生的频率足以成为一个主要问题（25%？）。
客户端上的任何东西实际上都能够摧毁“企业级”数据库，这真是令人惊讶。谁能分享有关如何提高稳健性的技巧，并希望帮助我理解为什么会发生这种情况？谢谢，米
You can see the combination of software components I'm using in the title of the question.
I have a simple 10-table database running on a Postgres server (Win 7 Pro). I have client apps (python using psycopg to connect to Postgres) who connect to the database at random intervals to conduct relatively light transactions. There's only one client app at a time doing any kind of heavy transaction, and those are typically < 500ms. The rest of them spend more time connecting than actually waiting for the database to execute the transaction. The point is that the database is under light load, but the load is evenly split between reads and writes.
My client apps run as servers/services themselves. I've found that it is pretty common for me to be able to (1) take the Postgres server completely down, and (2) ruin the database by killing the client app with a keyboard interrupt.
By (1), I mean that the Postgres process on the server aborts and the service needs to be restarted.
By (2), I mean that the database crashes again whenever a client tries to access the database after it has restarted and (presumably) finished "recovery mode" operations. I need to delete the old database/schema from the database server, then rebuild it each time to return it to a stable state. (After recovery mode, I have tried various combinations of Vacuums to see whether that improves stability; the vacuums run, but the server will still go down quickly when clients try to access the database again.)
I don't recall seeing the same effect when I kill the client app using a "taskkill" - only when using a keyboard interrupt to take the python process down. It doesn't happen all the time, but frequently enough that it's a major concern (25%?).
Really surprised that anything on a client would actually be able to take down an "enterprise class" database. Can anyone share tips on how to improve robustness, and hopefully help me to understand why this is happening in the first place? Thanks, M
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您遇到像这样的 postgresql 问题，您应该阅读此页面：
http://wiki。 postgresql.org/wiki/Guide_to_reporting_problems
有关真实错误的示例，以及如何提出获得操作和答案的问题，请阅读此主题。
http://archives.postgresql.org/pgsql-general/2010-12 /msg01030.php
If you're having problems with postgresql acting up like this, you should read this page:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
For an example of a real bug, and how to ask a question that gets action and answers, read this thread.
http://archives.postgresql.org/pgsql-general/2010-12/msg01030.php