当您在 PostgreSQL 中发现错误时，我们希望得到您的反馈。您的错误报告在提高 PostgreSQL 的可靠性方面起着重要作用，因为即使是最细致的注意也无法保证 PostgreSQL 的所有部分都能在所有平台、所有情况下正常工作。
以下建议旨在帮助您编写易于处理的错误报告。没有人强制要求遵循这些建议，但这样做通常对每个人都有益。
我们无法保证立即修复所有错误。如果错误显而易见、至关重要或影响许多用户，那么很可能有人会进行调查。也可能我们会告诉您更新到新版本以查看错误是否仍然存在。或者我们可能会决定在计划进行的重大重写完成之前无法修复该错误。或者它可能太难了，而且议程上还有更重要的事情。如果您需要立即获得帮助，请考虑购买商业支持合同。
在报告错误之前，请仔细阅读文档，以确认您尝试的操作确实是允许的。如果文档中不清楚您是否可以执行某项操作，也请报告；这是文档中的错误。如果事实证明程序的操作与文档不符，那就是一个错误。这可能包括但不限于以下情况：
程序以致命信号或操作系统错误消息终止，这些消息会指向程序中的问题。（例如，“磁盘已满”消息可能不是一个反例，因为您需要自己解决。）
程序对任何给定输入产生错误的输出。
程序拒绝接受有效输入（根据文档定义）。
程序在没有通知或错误消息的情况下接受无效输入。但请记住，您认为的无效输入可能是我们认为的扩展或与传统实践的兼容性。
PostgreSQL 在支持的平台上未能根据说明进行编译、构建或安装。
此处“程序”指的是任何可执行文件，而不仅仅是后端进程。
运行缓慢或占用大量资源不一定是错误。请阅读文档或在邮件列表中寻求有关调整应用程序的帮助。不遵守SQL标准也不一定是错误，除非明确声明了对特定功能的兼容性。
在继续之前，请检查 TODO 列表和 FAQ，看看您的错误是否已知。如果您无法解读 TODO 列表中的信息，请报告您的问题。我们至少可以做的是让 TODO 列表更清晰。
关于错误报告最重要的一点是陈述所有事实，并且只陈述事实。不要猜测您认为哪里出错了，“它似乎做了什么”，或者程序的哪个部分有故障。如果您不熟悉实现，您很可能会猜错，无济于事。即使您熟悉，有根据的解释也是事实的绝佳补充，但不能替代事实。如果我们打算修复错误，我们仍然需要先自己看到它发生。报告纯粹的事实相对直接（您可能可以从屏幕上复制粘贴），但由于有人认为细节不重要或报告会被理解，因此常常会遗漏重要的细节。
每次错误报告都应包含以下内容：
从程序启动开始，重现问题的确切步骤。这应该是自包含的；仅发送一个裸露的 SELECT 语句而不发送前面的 CREATE TABLE 和 INSERT 语句是不够的，因为输出可能取决于表中的数据。我们没有时间来逆向工程您的数据库模式，如果我们必须自己创建数据，我们可能会错过问题。
对于 SQL 相关问题，最好的测试用例格式是一个可以通过 psql 前端运行并显示问题的脚本文件。（确保您的 ~/.psqlrc 启动文件为空。）创建此文件的简便方法是使用 pg_dump 转储设置场景所需的表声明和数据，然后添加问题查询。鼓励您最小化示例的大小，但这并非绝对必要。如果错误是可重现的，我们总会找到它。
如果您的应用程序使用了其他客户端接口，例如 PHP，请尝试隔离有问题的查询。我们可能不会设置 Web 服务器来重现您的问题。无论如何，请务必提供确切的输入文件；不要猜测问题发生在“大文件”或“中型数据库”等情况下，因为这些信息过于不精确，无法使用。
您收到的输出。请不要说“它无法工作”或“崩溃了”。如果有错误消息，请显示它，即使您不理解。如果程序因操作系统错误而终止，请说明是哪个错误。如果根本没有发生任何事情，请说明。即使您的测试用例的结果是程序崩溃或其他明显的行为，它也可能不会发生在我们的平台上。最简单的方法是尽可能从终端复制输出。
如果您正在报告错误消息，请获取最详细的消息形式。在 psql 中，请事先执行 \set VERBOSITY verbose。如果您从服务器日志中提取消息，请将运行参数 log_error_verbosity 设置为 verbose，以便记录所有详细信息。
在发生致命错误的情况下，客户端报告的错误消息可能不包含所有可用信息。请同时查看数据库服务器的日志输出。如果您不保留服务器的日志输出，现在是时候开始了。
您期望的输出非常重要。如果您只写“此命令给我这个输出。”或“这不是我期望的。”，我们可能会自己运行它，扫描输出，并认为它看起来没问题，并且正是我们期望的。我们不应该花时间来解析您的命令背后的确切语义。特别要避免仅仅说“这不符合 SQL 的说法/Oracle 的做法。”挖掘正确的行为SQL不是一件有趣的事情，我们也不知道外面所有其他关系型数据库是如何运作的。（如果您的难题是程序崩溃，您可以显然省略此项。）
任何命令行选项和其他启动选项，包括您从默认值修改过的任何相关环境变量或配置文件。再次，请提供确切的信息。如果您使用的是预打包的分发版，该分发版会在启动时启动数据库服务器，您应该找出它是如何完成的。
您对安装说明所做的任何与说明不同的操作。
PostgreSQL 版本。您可以运行命令 SELECT version(); 来查找您连接到的服务器版本。大多数可执行程序也支持 --version 选项；至少 postgres --version 和 psql --version 应该可以工作。如果函数或选项不存在，那么您的版本就足够老了，需要升级。如果您运行的是预打包版本，例如 RPM，请说明，包括软件包可能有的任何子版本。如果您讨论的是 Git 快照，请说明，包括提交哈希。
如果您的版本低于 18.0，我们几乎肯定会告诉您升级。每个新版本都有许多错误修复和改进，因此您在旧版本 PostgreSQL 中遇到的错误很可能已经被修复了。我们只能为使用旧版本 PostgreSQL 的站点提供有限的支持；如果您需要我们无法提供的帮助，请考虑购买商业支持合同。
平台信息。这包括内核名称和版本、C 库、处理器、内存信息等。在大多数情况下，提供供应商和版本信息就足够了，但不要假设每个人都知道“Debian”具体包含什么，或者每个人都在 x86_64 上运行。如果您遇到安装问题，那么您机器上的工具链（编译器、make 等）的信息也是必需的。
如果您的错误报告变得相当冗长，请不要害怕。这是生活的一部分。第一次报告所有内容比我们不得不费力挤出事实要好。另一方面，如果您的输入文件很大，您可以先询问是否有人有兴趣研究一下。这里有一篇 文章，其中概述了更多关于报告错误的技巧。
不要花所有时间来弄清楚输入中的哪些更改会导致问题消失。这可能无助于解决问题。如果事实证明该错误无法立即修复，您仍然有时间找到并分享您的解决方案。此外，再说一遍，不要浪费时间猜测错误存在的原因。我们会很快找出原因的。
在编写错误报告时，请避免使用含糊不清的术语。整个软件包称为“PostgreSQL”，有时简称为“Postgres”。如果您具体谈论的是后端进程，请说明，不要只说“PostgreSQL 崩溃了”。单个后端进程的崩溃与父“postgres”进程的崩溃是截然不同的；如果您是指单个后端进程崩溃，请不要说“服务器崩溃了”，反之亦然。此外，客户端程序，例如交互式前端“psql”，与后端完全分开。请尽量具体说明问题是在客户端还是服务器端。
一般来说，请将错误报告发送到错误报告邮件列表 <pgsql-bugs@lists.postgresql.org>。我们要求您为电子邮件消息使用描述性的主题，可能包含错误消息的一部分。
另一种方法是填写项目 网站上提供的错误报告 Web 表单。以这种方式提交错误报告会将其发送到 <pgsql-bugs@lists.postgresql.org> 邮件列表。
如果您的错误报告涉及安全问题，并且您不希望它立即在公开存档中可见，请不要将其发送到 pgsql-bugs。安全问题可以私下报告给 <security@postgresql.org>。
请勿将错误报告发送给任何用户邮件列表，例如 <pgsql-sql@lists.postgresql.org> 或 <pgsql-general@lists.postgresql.org>。这些邮件列表用于回答用户问题，其订阅者通常不希望收到错误报告。更重要的是，他们不太可能修复它们。
另外，请不要将报告发送给开发人员邮件列表 <pgsql-hackers@lists.postgresql.org>。此列表用于讨论 PostgreSQL 的开发，并且我们希望将错误报告分开。如果问题需要进一步审查，我们可能会选择在 pgsql-hackers 上讨论您的错误报告。
如果您对文档有疑问，最好的报告方式是文档邮件列表 <pgsql-docs@lists.postgresql.org>。请具体说明您对文档的哪个部分不满意。
如果您的错误是在不受支持的平台上出现的兼容性问题，请发送邮件至 <pgsql-hackers@lists.postgresql.org>，以便我们（和您）可以努力将 PostgreSQL 移植到您的平台。
由于不幸的垃圾邮件量，上述所有列表都将受到审核，除非您已订阅。这意味着电子邮件传递会有一些延迟。如果您想订阅列表，请访问 https://lists.postgresql.org/ 获取说明。
如果您在文档中看到任何不正确、与您在特定功能上的实际体验不符或需要进一步澄清的内容，请使用 此表单 来报告文档问题。