当您在 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 快照，请提及它，包括提交哈希。
如果您的版本低于 17.0，我们几乎肯定会告诉您升级。每个新版本都有许多错误修复和改进，因此您在较旧版本的 PostgreSQL 中遇到的错误很可能已在修复。我们只能为使用旧版 PostgreSQL 的站点提供有限的支持；如果您需要超出我们所能提供的支持，请考虑获取商业支持合同。
平台信息。这包括内核名称和版本、C 库、处理器、内存信息等。在大多数情况下，报告供应商和版本就足够了，但不要假设每个人都知道 “Debian” 究竟包含什么或每个人都在 x86_64 上运行。如果您遇到安装问题，那么您机器上的工具链（编译器、make 等）的信息也是必要的。
如果您的错误报告变得相当冗长，请不要害怕。这是生活中的常态。最好是一次性报告所有信息，而不是让我们不得不从您那里挤出事实。另一方面，如果您的输入文件很大，那么先询问一下是否有人有兴趣调查也是合理的。这里有一篇文章概述了关于报告错误的一些更多提示。
不要花费所有时间来找出输入中的哪些更改可以使问题消失。这可能无助于解决问题。如果事实证明该错误无法立即修复，您仍然有时间找到并分享您的解决方法。此外，再次强调，不要浪费时间猜测错误存在的原因。我们很快就会发现这一点。
在编写错误报告时，请避免使用混淆的术语。整个软件包称为“PostgreSQL”，有时简称为“Postgres”。如果您特别谈论的是后端进程，请提及这一点，不要只说“PostgreSQL崩溃了”。单个后端进程的崩溃与父“postgres”进程的崩溃完全不同；请不要在指单个后端进程停止运行时说“服务器崩溃了”，反之亦然。此外，诸如交互式前端“psql”之类的客户端程序与后端完全分离。请尝试明确说明问题是在客户端还是服务器端。
一般来说，将错误报告发送到错误报告邮件列表 <[email protected]>。请您为您的电子邮件消息使用描述性主题，例如错误消息的部分内容。
另一种方法是填写项目网站上提供的错误报告网络表单。通过这种方式输入错误报告会导致它被邮件发送到<[email protected]>邮件列表。
如果您的错误报告存在安全隐患，并且您希望它不会立即在公共档案中可见，请不要将其发送到pgsql-bugs。安全问题可以私下报告到<[email protected]>。
不要将错误报告发送到任何用户邮件列表，例如<[email protected]>或<[email protected]>。这些邮件列表用于回答用户问题，并且其订阅者通常不希望收到错误报告。更重要的是，他们不太可能修复它们。
此外，请不要将报告发送到开发人员邮件列表<[email protected]>。此列表用于讨论PostgreSQL的开发，如果我们可以将错误报告分开，那就太好了。如果问题需要更多审查，我们可能会选择在pgsql-hackers上讨论您的错误报告。
如果您在文档方面遇到问题，最好的报告地点是文档邮件列表<[email protected]>。请具体说明您对文档的哪一部分不满意。
如果您的错误是在不受支持的平台上的可移植性问题，请发送邮件到<[email protected]>，以便我们（以及您）可以将PostgreSQL移植到您的平台上。
由于不幸的是存在大量的垃圾邮件，因此除非您已订阅，否则上述所有列表都将进行审核。这意味着电子邮件在发送之前会有一定的延迟。如果您希望订阅这些列表，请访问https://lists.postgresql.org/获取说明。
如果您在文档中看到任何不正确的内容，与您对特定功能的体验不符，或者需要进一步澄清，请使用此表单报告文档问题。