当你在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 快照，也请说明，并给出提交哈希值。
如果你的版本早于 14.22，我们几乎肯定会建议你升级。每个新版本都会包含大量缺陷修复和改进，因此你在旧版 PostgreSQL中遇到的缺陷，很可能已经被修复。对于使用旧版 PostgreSQL的站点，我们只能提供有限支持；如果你需要超出这一范围的帮助，请考虑购买商业支持合同。
平台信息。这包括内核名称和版本、C 库、处理器、内存信息等。在大多数情况下，报告供应商和版本就足够了，但不要想当然地认为所有人都知道 “Debian”具体包含什么，或者所有人都运行在 x86_64 上。如果你遇到的是安装问题，那么你机器上的工具链信息（编译器、make等）也是必需的。
不要担心你的缺陷报告会变得很长；这很正常。第一次就把所有内容都报告出来，总比让我们反复追问细节要好。另一方面，如果你的输入文件非常大，先问问是否有人愿意看一看，也是合理的。这里有一篇 文章，概述了更多关于报告缺陷的建议。
不要把全部时间都花在找出输入中的哪些变化会让问题消失上。这多半无助于解决问题。如果最后发现这个缺陷无法立刻修复，你仍然有时间去寻找并分享变通办法。还有，再强调一次，不要浪费时间去猜测这个缺陷为什么存在。我们迟早会查明原因。
在编写缺陷报告时，请避免使用含混的术语。整个软件包叫作“PostgreSQL”，有时简称 “Postgres”。如果你特指后端进程，请明确说出来，不要只是说 “PostgreSQL 崩溃了”。单个后端进程崩溃，与父“postgres”进程崩溃，是完全不同的事情；当你指的是某个单独的后端进程挂掉时，请不要说 “服务器崩溃了”，反过来也一样。此外，客户端程序，例如交互式前端 “psql”，与后端完全是分开的。请尽量明确问题是在客户端还是服务器端。
一般来说，请将缺陷报告发送到缺陷报告邮件列表 <pgsql-bugs@lists.postgresql.org>。请为电子邮件使用描述性的主题，必要时可以摘取部分错误消息。
另一种方法是填写项目 网站上提供的缺陷报告网页表单。通过这种方式提交的缺陷报告，也会被发送到 <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/获取说明。
如果您发现文档中有不正确的内容、与您使用特定功能的经验不符或需要进一步说明，请使用此表单来报告文档问题。