这个问题在第一个客户端被授予对第一台计算机的完全访问权限后大约两分钟开始出现，并且从那以后它就没有消失。每当有人优先考虑快速完成面向业务的工作时，他们都会对此马虎，并为每个人搞砸事情。这就是事情的运作方式，因为正确的设计和实施比廉价的黑客更难。你不会解决这个问题，你所能做的就是弄清楚如何让客户更容易与你合作而不是反对你。如果你做得对，它会看起来像优质的服务而不是唠叨。
首先，数据库方面。现在有一种方法可以控制 PostgreSQL 中的查询资源。主要的困难是像“nice”这样的工具控制 CPU 使用率，但如果数据库不适合 RAM，那么很可能是 I/O 使用率正在扼杀你。请参阅此开发人员消息，在此处总结问题。
现在，如果实际上是客户端正在烧毁的 CPU，您可以使用两种技术来改善这种情况：
- 安装一个更改进程优先级的 C 函数（示例 1，示例 2），并确保每当他们运行某些东西时，它首先被调用（可能将其放入他们的 psql 配置文件中，还有其他方法）。
- 编写一个脚本，查找由其用户 ID 生成的 postmaster 进程并对其进行修改，使其经常在 cron 中运行或作为守护进程运行。
听起来您的问题不是他们正在运行的特定查询进程，而是他们对更大结构所做的其他修改。只有一种方法可以解决这个问题：您必须像对待入侵者一样对待客户，并使用计算机安全领域的那部分方法来检测他们什么时候搞砸了。严重地！在服务器上安装一个像 Tripwire 这样的入侵检测系统（有更好的工具，这只是典型的例子），当它们接触到任何东西时它会提醒你。新文件是 0777？应该直接跳出正确的 IDS 报告。
在数据库方面，您无法直接检测到正在修改的数据库是否有用。您应该每天将架构的 pg_dump 放入一个文件（pg_dumpall -g和pg_dump -s，然后将其与您交付的最后一个文件进行比较，并在更改时再次提醒您。如果您管理得很好，与客户变成“我们注意到你在服务器上发生了变化......你想用它来完成什么？”这让你看起来你真的在关注他们。这可以变成一个销售机会，并且他们可能会停止摆弄东西，就像知道你会立即抓住它一样。
您应该立即开始做的另一件事是在每个客户端上安装尽可能多的版本控制软件。您应该能够登录到每个系统，运行适当的状态/差异工具进行安装，并查看发生了什么变化。也定期将其邮寄给您。同样，如果与将架构作为组件转储到其管理的内容的东西结合使用，效果最好。没有足够多的人对数据库中的代码使用严格的版本控制方法。
这是这里有用的主要技术方法集。剩下的就是一个经典的咨询客户管理问题，它更多的是人的问题，而不是计算机的问题。振作起来，情况可能更糟——如果你给他们 ODBC 访问权限并且他们发现他们可以在 Access 或类似的简单的东西中编写自己的查询，FSM 会帮助你。