pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
当你在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 快照，也请说明，并给出提交哈希值。
如果你的版本早于 9.1.24，我们几乎肯定会建议你升级。每个新版本都会包含大量缺陷修复和改进，因此你在旧版 PostgreSQL中遇到的缺陷，很可能已经被修复。对于使用旧版 PostgreSQL的站点，我们只能提供有限支持；如果你需要超出这一范围的帮助，请考虑购买商业支持合同。
平台信息。这包括内核名称和版本、C 库、处理器、内存信息等。在大多数情况下，报告供应商和版本就足够了，但不要想当然地认为所有人都知道 “Debian”具体包含什么，或者所有人都运行在 i386 上。如果你遇到的是安装问题，那么你机器上的工具链信息（编译器、make等）也是必需的。
Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It is better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it. Here is an article that outlines some more tips on reporting bugs.
不要把全部时间都花在找出输入中的哪些变化会让问题消失上。这多半无助于解决问题。如果最后发现这个缺陷无法立刻修复，你仍然有时间去寻找并分享变通办法。还有，再强调一次，不要浪费时间去猜测这个缺陷为什么存在。我们迟早会查明原因。
在编写缺陷报告时，请避免使用含混的术语。整个软件包叫作“PostgreSQL”，有时简称 “Postgres”。如果你特指后端进程，请明确说出来，不要只是说 “PostgreSQL 崩溃了”。单个后端进程崩溃，与父“postgres”进程崩溃，是完全不同的事情；当你指的是某个单独的后端进程挂掉时，请不要说 “服务器崩溃了”，反过来也一样。此外，客户端程序，例如交互式前端 “psql”，与后端完全是分开的。请尽量明确问题是在客户端还是服务器端。
一般来说，请将缺陷报告发送到缺陷报告邮件列表 <pgsql-bugs@postgresql.org>。请为电子邮件使用描述性的主题，必要时可以摘取部分错误消息。
另一种方法是填写项目 网站上提供的缺陷报告网页表单。通过这种方式提交的缺陷报告，也会被发送到 <pgsql-bugs@postgresql.org>邮件列表。
如果你的缺陷报告涉及安全影响，而且你不希望它立刻出现在公开归档中，请不要发送到 pgsql-bugs。安全问题可以私下报告给 <security@postgresql.org>。
不要将缺陷报告发送到任何用户邮件列表，例如 <pgsql-sql@postgresql.org>或 <pgsql-general@postgresql.org>。这些邮件列表用于回答用户问题，其订阅者通常并不希望收到缺陷报告。更重要的是，他们也不太可能去修复这些缺陷。
此外，请不要把报告发送到开发者邮件列表 <pgsql-hackers@postgresql.org>。这个列表是用来讨论 PostgreSQL开发的，最好把缺陷报告和这类讨论分开。如果这个问题需要更深入的审查，我们可能会选择在 pgsql-hackers上继续讨论你的缺陷报告。
如果你遇到的是文档问题，报告它的最佳地点是文档邮件列表 <pgsql-docs@postgresql.org>。请明确指出你对文档的哪一部分不满意。
如果你的缺陷是在某个不受支持平台上出现的可移植性问题，请发送邮件到 <pgsql-hackers@postgresql.org>，这样我们（以及你）就可以共同推进 PostgreSQL在该平台上的移植工作。
由于垃圾邮件泛滥，上述所有电子邮件地址都是封闭邮件列表。也就是说，你必须订阅某个列表才能向它发帖。 （不过，使用缺陷报告 Web 表单无需订阅。）如果你希望发邮件但不想接收列表邮件， 可以订阅并把订阅选项设置为nomail。要了解更多信息，请向 <majordomo@postgresql.org>发送邮件，正文只写一个词help。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。