问题汇报指导

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

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

标识臭虫

• 程序带着一个致命信号或者一个指向程序错误的操作系统错误信息（一个反例是一个"disk full"（磁盘满）信息，因为这样的错误必须在Postgres 外部进行修复）退出。


程序对给出的任何输入都产生错误的输出。

程序拒绝接收有效的输入。

程序对非法输入没有生成任何提示或者错误信息。

在支持的平台上根据指导未能成功地编译、制作或安装PostgreSQL。

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

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

汇报什么

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

• 从程序启动开始到重现问题的准确步骤顺序。这应该自包含；要知道如果输出将依赖于表中的数据时，光把一个光秃秃的 select 语句发过来而不吧前面的创建表和插入语句发过来是不够的。我们没有时间分析你的数据库结构，而且如果我们试着建立我们自己的数据，那我们就有可能错过问题。测试与查询语言有关的问题的最好的格式是一个可以通过 psql 前端运行并显示问题的文件。（确保在你的 ~/.psqlrc 启动文件里面没有任何东西。）我们鼓励你最小化你的例子，但这不是非做不可的事情。如果臭虫是可以复现的，那么两种方式都能帮助我们找到它。


如果你的应用使用其他客户端接口，比如说 PHP，那么请设法隔离出有毛病的查询。我们可能不会设置一个 web 服务器来复现你的问题。不管怎么说，请记住提供准确的输入文件，而不要猜测问题会在"大文件"或者"中等尺寸的数据库"等等的身上发生。因为这样的信息太不确切，因而没有什么用处。

你得到的输出。请不要说它"不起作用"或者"失灵了"。如果有错误信息，请写明，即使你不能理解也一样。如果程序带着操作系统错误退出，也请写清楚。如果什么也没有发生，就照直说。即使你的测试实例是程序崩溃或者其他显而易见的现象，它也有可能不会在我们的平台上发生。如果可能，最简单的事情是从终端拷贝输出。

注意：如果是致命错误，客户端提供的信息可能不会包含所有能得到的信息。这种情况下，还要看看数据库服务器的输出。如果你没有保留你的服务器输出，那么现在是做这件事的好机会。

还有一样很重要去声明的是你期望的输出。如果你只是写到"这条命令给我这样的输出。"或者"这不是我期望的。"，我们可能自己运行它，检查输出，然后认为看上去很好并且正是我们所期望的输出。我们不应该把时间花在解析你的命令的语义上。特别是要避免仅仅说"这不是 SQL 说的/Oracle 做的那样。" 从 SQL 里挖掘出正确的特性可不是好玩的事情，我们也不能知道所有其他的关系数据库的特性是怎样的。（如果你的问题是程序崩溃，你显然可以忽略这个条目。）

任何命令行选项和其他启动选项，包括相关的环境变量或者你从缺省值修改以后的配置文件。同时，还要准确。如果你使用启动系统时自动启动数据库服务器的预打包的版本，你应该试着找出这些是怎样实现的。

任何你做得与安装指导不一样的东西。

PostgreSQL 版本。你可以运行命令 SELECT version()；来检查你正在运行的版本是什么。如果这个函数不存在，请说明，这样我们就知道你的版本有够老。如果你无法启动服务器或者客户端，参阅源码目录里面的 README 文件或者看看你的发布文件的名称或包名称。如果你的版本早于 7.0，我们几乎可能会告诉你去升级。每个新版本都会有成吨的臭虫被修理掉，这也是我们写（新版本）的原因。

如果你运行预打包的版本，例如 RPM，请说明，包括那个包可能有的任何子版本号。如果你说的是 CVS 快照，说明之，包括它的日期和时间。

平台信息。这包括内核名称和版本，C 库，处理器，存储器信息。大多数情况下只需要汇报供应商和版本，但是不要指望每个人都很清楚 "Debian" 包括什么东西或者说每个人都运行在 Pentium 上。如果你还有关于编译器，make等安装的问题信息，也有必要详细汇报。

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

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

到哪里汇报臭虫

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

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

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

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

注意：由于我们不愿意看到的各种各样的垃圾邮件，上面的所有电子邮件地址都是封闭的邮件地址。也就是说，你需要先申请，然后才能发帖子。如果你只是想发送邮件而不想接受列表的往来的邮件，你可以提交特殊的 pgsql-loophole 邮件列表，那里允许你向所有 PostgreSQL 邮件列表发信而接收不到任何信息。向 pgsql-loophole-request@postgresql.org 发邮件来申请。

（译注：这里用"assume"这个词真多，让我想起一个老外给我讲解"assume"的意思："ass-u-me" :-D）