5. 错误报告准则

• 5 .1.识别错误

• 5 .2.报告什么

• 5 .3.在哪里报告错误

当您在 PostgreSQL 中发现错误时，我们想听听它。您的错误报告在使 PostgreSQL 更可靠的过程中起着重要的作用，因为即使在最大的注意下也不能保证 PostgreSQL 的每个部分在任何情况下都可以在每个平台上运行。

以下建议旨在帮助您形成可以有效处理的错误报告。没有人需要跟随他们，但是这样做往往对每个人都是有利的。

我们不能保证立即修复每个错误。如果该错误是明显的，严重的或影响许多用户的，则很有可能有人会对其进行调查。我们还可能告诉您更新到较新版本，以查看错误是否在那里发生。或者我们可能决定在计划进行的一些重大重写之前无法修复该错误。也许这太简单了，议程上还有更重要的事情。如果您立即需要帮助，请考虑获取商业支持 Contract。

5 .1.识别错误

在报告错误之前，请阅读并重新阅读文档以确认您确实可以做任何尝试。如果文档中不清楚您是否可以做某事，请报告。这是文档中的错误。如果事实证明某个程序所做的事情与文档中所说的有所不同，那就是一个错误。这可能包括但不限于以下情况：

• 程序以致命 signal 或 os 错误消息终止，该错误消息或错误消息指出了程序中的问题。 (一个反例可能是“磁盘已满”消息，因为您必须自己进行修复.)

• 程序为任何给定的 Importing 产生错误的输出。

• 程序拒绝接受有效 Importing(如文档中所定义)。

• 程序接受无效的 Importing 而没有通知或错误消息。但是请记住，您对无效 Importing 的想法可能是我们对传统做法的扩展或兼容。

• PostgreSQL 无法根据支持的平台上的说明进行编译，构建或安装。

这里的“程序”是指任何可执行文件，而不仅仅是后端进程。

变慢或占用资源不一定是错误。阅读文档或在其中一个邮件列表上询问以获取有关调整应用程序的帮助。除非明确声明符合特定功能，否则不遵守 SQL 标准也不一定是 bug。

在 continue 之前，请检查“待办事项”列表和“常见问题”中的内容，以了解是否已经知道您的错误。如果您无法解码 TODO 列表中的信息，请报告您的问题。我们要做的至少是使 TODO 列表更清晰。

5 .2.报告什么

关于错误报告，要记住的最重要的事情是 Statements 所有事实，并且仅 Statements 事实。不要猜测您认为出了什么问题，“它似乎有什么问题”或程序的哪一部分出了故障。如果您不熟悉该实现，则可能会猜错并且对我们没有帮助。即使您是有教养的解释者，也是对事实的很好补充，但不能替代事实。如果我们要修复该错误，我们仍然必须首先看到它自己发生。报告裸露的事实相对简单(您可以从屏幕上复制并粘贴)，但由于人们认为这无关紧要，或者总是可以理解该报告，因此常常遗漏了重要的细节。

每个错误报告中都应包含以下各项：

• 重现问题所需的步骤(从程序启动*开始)的确切 Sequences。这应该是独立的；如果输出应取决于表中的数据，则仅发送裸露的SELECT语句而没有前面的CREATE TABLE和INSERT语句是不够的。我们没有时间对您的数据库架构进行逆向工程，并且如果我们应该组成自己的数据，我们可能会错过这个问题。

对于与 SQL 相关的问题的测试用例，最好的格式是可以通过显示问题的 psql 前端运行的文件。 (确保~/.psqlrc启动文件中没有任何内容.)创建此文件的一种简单方法是使用 pg_dump 转储设置场景所需的表声明和数据，然后添加问题查询。我们鼓励您最小化示例的大小，但这不是绝对必要的。如果该错误是可复制的，我们会以任何一种方式找到它。

如果您的应用程序使用其他 Client 端接口(例如 PHP)，则请尝试隔离有问题的查询。我们可能不会设置 Web 服务器来重现您的问题。无论如何，请记住提供准确的 Importing 文件；不要猜测“大文件”或“中型数据库”等问题会发生，因为此信息过于不精确而无法使用。

• 您得到的输出。请不要说它“没用”或“崩溃”。如果有错误消息，请显示它，即使您不理解也是如此。如果程序因 os 错误而终止，请说出哪个。如果什么都没有发生，请说出这一点。即使您的测试用例的结果是程序崩溃或其他明显的情况，也可能不会在我们的平台上发生。如果可能的话，最简单的方法是从终端复制输出。

• 预期的输出状态非常重要。如果您只写“此命令给了我该输出”。或“这不是我所期望的。”，我们可以自己运行它，扫描输出，并认为它看起来不错，并且正是我们所期望的。我们不必花时间解码命令背后的确切语义。特别要避免只说“这不是 SQL 所说的/ Oracle 所做的”。从 SQL 找出正确的行为并不是一件容易的事，我们也不知道那里的所有其他关系数据库的行为如何。 (如果您的问题是程序崩溃，则显然可以省略此项目.)

• 任何命令行选项和其他启动选项，包括您从默认值更改的任何相关环境变量或配置文件。同样，请提供准确的信息。如果使用的是预先打包的发行版，该发行版在引导时启动数据库服务器，则应尝试找出实现方法。

• 您所做的一切与安装说明完全不同。

• PostgreSQL 版本。您可以运行命令SELECT version();来查找所连接服务器的版本。大多数可执行程序还支持--version选项。至少postgres --version和psql --version应该起作用。如果该功能或选项不存在，则您的版本已经足够旧，无法升级。如果您运行的是预打包版本(例如 RPM)，请说出来，包括该软件包可能具有的所有子版本。如果您正在谈论 Git 快照，请提及它，包括提交哈希。

如果您的版本早于 11.8，我们几乎肯定会告诉您进行升级。每个新发行版都有许多错误修复和改进，因此很可能已经修复了旧版本 PostgreSQL 中遇到的错误。我们只能为使用旧版 PostgreSQL 的网站提供有限的支持；如果您的需求超出我们的能力范围，请考虑获取商业支持 Contract。

• 平台信息。这包括内核名称和版本，C 库，处理器，内存信息等。在大多数情况下，报告供应商和版本就足够了，但不要假设每个人都知道“ Debian”的确切含义或每个人都在 x86_64 上运行。如果您有安装问题，则还需要有关计算机上的工具链(编译器，制造商等)的信息。

如果您的错误报告变得很冗长，请不要害怕。那是生活中的事实。最好是第一时间举报所有事情，而不是我们不得不从事实中挤出事实。另一方面，如果您的 Importing 文件很大，那么首先要问是否有人有兴趣研究它是公平的。这是article，概述了有关报告错误的更多提示。

不要花费所有时间来找出 Importing 中的哪些更改可以使问题消失。这可能无济于事。如果事实证明该错误不能立即修复，您仍然有时间找到并分享您的解决方法。同样，不要再浪费时间猜测错误存在的原因。我们会尽快发现这一点。

编写错误报告时，请避免混淆术语。该软件包总共称为“ PostgreSQL”，有时简称为“ Postgres”。如果您专门谈论后端过程，请提及，不要仅仅说“ PostgreSQL 崩溃”。单个后端进程的崩溃与父级“ postgres”进程的崩溃完全不同。当您表示单个后端进程出现故障时，请不要说“服务器崩溃”，反之亦然。而且，诸如交互式前端“ psql”之类的 Client 端程序与后端是完全分开的。请尝试具体说明问题是在 Client 端还是在服务器端。

5 .3.在哪里报告错误

通常，将错误报告发送到<[email protected]>的错误报告邮件列表。要求您使用描述性主题作为电子邮件消息，可能是错误消息的一部分。

另一种方法是填写位于项目web site的错误报告网络表单。以这种方式 Importing 错误报告会导致将其发送到<[email protected]>邮件列表。

如果您的错误报告涉及安全问题，并且您希望它不会在公共 Files 中立即变得可见，请不要将其发送到pgsql-bugs。可以向<[email protected]>私下报告安全问题。

不要将错误报告发送到任何用户邮件列表，例如<[email protected]>或<[email protected]>。这些邮件列表用于回答用户问题，其订阅者通常不希望收到错误报告。更重要的是，他们不太可能修复它们。

另外，请不要将报告发送到开发人员的邮件列表<[email protected]>。该列表用于讨论 PostgreSQL 的开发，如果我们可以将错误报告分开放置，将是很好的。如果问题需要更多检查，我们可能选择在pgsql-hackers上讨论关于您的错误报告的问题。

如果您对文档有疑问，最好的报告方法是文档邮件列表<[email protected]>。请具体说明您不满意的文档部分。

如果您的错误是不支持平台上的可移植性问题，请将邮件发送到<[email protected]>，以便我们(和您)可以将 PostgreSQL 移植到您的平台上。