5. 问题汇报指导

当你在 PostgreSQL 里碰到臭虫时, 我们也希望能听到它。你的臭虫汇报是将 PostgreSQL 做得更加 可靠的一个非常重要的部分, 因为再细致的工作也不能保证在任何情况任何平台下 PostgreSQL 的 每一个部分都能正常工作。

下面的建议试图帮助你正确格式化臭虫报告, 这样这些报告就能够以一种有效的方法处理。我们不强迫任何人 遵循这些东西,但是这样做对我们每个人都有好处。

我们不能保证能够马上修补每个臭虫。如果臭虫是显而易见的, 很关键的或者影响许多用户,那么很有可能有 些人会认真检查它们。同样我们也可能是告诉你升级到一个新版本, 看看臭虫是否仍然存在。否则,我们可能 会说这个臭虫在我们正计划的几个主要改写之前不会得到修补。 或者这个臭虫只是太费事了,而且目前的日程 表上有更重要的事情要做。如果你立即需要帮助, 那么请考虑获取一个商业性的支持。

5.1. 标识臭虫

在你报告臭虫之前这样的问题之前,请一再仔细地读文档, 以确认你确实可以做你在做的事情。如果 文档中对你能否处理你所做的事情并不清楚,也请你汇报过来; 因为这个是文档的臭虫。如果发现你的程序的 表现不象文档里说的那样,那就是一个臭虫。 这时可能包括(不过不一定局限于)下面的现象:

这里的 "程序" 代表任何可执行文件,而不仅仅是后端服务器。

速度慢或者资源消耗大不算是臭虫。 请阅读文档或者提交邮件列表之一获取调节你的应用(的性能)的帮助。 未能遵循 SQL 也不算是一个臭虫, 除非(文档)明确声明了遵守该特定特性。

在你准备继续汇报臭虫之前,请检查 TODO 列表和 FAQ, 看看你报告的臭虫是否已知。如果你不能解析 TODO 列表里面的信息,请汇报你的问题。 至少我们可以把 TODO 列表做得更清晰。

5.2. 汇报什么

关于汇报臭虫需要记住的最重要的事就是写出所有事实并且只写事实。 不要推测你认为是什么错了,什么"看起 来象",或者是推测程序的哪一部分失灵了。 如果你不熟悉 PostgreSQL 的实现, 你很可能猜错因而不能帮我们任何忙。 而且即使你熟悉 Postgres 的实现, 提炼出来的解释也只是事实的补充而不是代替。如果我们准备修理这个 臭虫,我们仍然需要首先亲自看到臭虫的出现。 报告简单的事实相对而言比较直接(你可以从屏幕上拷贝和粘 贴),不过经常发生的是很多人认为这些事实不重要而忽略了重要的细节, 否则汇报总是能够被我们理解。

下面的条目应该包含在所有臭虫汇报里面:

不要怕你的臭虫汇报太长。这就是生活。 一开始就汇报所有的事情要比让我们从你那里挤出事实要好。另外, 如果你的输入文件非常巨大,先问问有没有人有兴趣查看它也是合理的。

不要把你的时间花在寻找如何通过修改输入来消除问题的方法上。 这样很可能不会对解决问题有任何帮助。 如果发现不能直接修理臭虫,你还有时间来查找和共享你的绕过方法。 还有,我们再说一便,不要在猜测臭虫 的位置上面浪费时间。我们能够及时找到错误。

在你书写臭虫汇报时,请选用不易混淆的术语。 软件包本身被称为"PostgreSQL",有时简称为 "Postgres"。 (有些时候用缩写 "Pgsql",但是请不要这么使用。)当你特指后端服务器时, 请明确说明,而不要仅仅是说"Postgres 崩溃了"。 交互前端(SQL 界面)叫做 "psql" 而且在所有用法和用途上都和后端完全分离。

5.3. 到哪里汇报臭虫

通常,把汇报发到 臭虫汇报邮件列表 。我们建议你为你的电子邮件消息选用一个描述性的题目, 也许就用错误信息的一部分。

不要把臭虫汇报发送到任何用户邮件列表里,例如 SQL 语言邮件列表 或 通用话题邮件列表 。这些邮件列表用于回答用户问题, 而且那些订阅者通常不希望接收臭虫汇报。 更重要的是,他们很可能不会修理这些臭虫。

还有,请不要向 开发者邮件列表 发送臭虫汇报。这个列表用于讨论 PostgreSQL 的开发, 因而我们很希望能和臭虫汇报分离开。 如果修理这个臭虫需要更多评论, 我们可能会在这个列表开一个关于你的臭虫的讨论会。

如果你觉得文档有问题,请发电子邮件到 文档邮件列表 。在你的问题汇报里面指明文档、章、节。

如果你的臭虫是一个在不支持平台上的移植性问题,向 移植性问题邮件列表 , 发送电子邮件,这样我们(还有你)可以一起尝试把 PostgreSQL 移植到你的平台上。

注意: 由于我们不愿意看到的各种各样的垃圾邮件, 上面的所有电子邮件地址都是封闭的邮件地址。 也就是说,你需要先申请,然后才能发帖子。 如果你只是想发送邮件而不想接受列表的往来的邮件, 你可以提交邮件并且把你的提交选项设置为nomail. 如果需要更多的信息, 你可以向 发送一封邮件,邮件的正文只有一个单词help 就可以了.