## 5.漏洞报告指南
[5.1. 识别错误](bug-reporting.html#id-1.3.8.5)
[5.2. 报告什么](bug-reporting.html#id-1.3.8.6)
[5.3. 在哪里报告错误](bug-reporting.html#id-1.3.8.7)
当你在PostgreSQL中发现一个bug时，我们想听听。您的错误报告在使PostgreSQL更可靠方面发挥了重要作用，因为即使非常小心也不能保证PostgreSQL的每个部分在任何情况下都能在每个平台上工作。
以下建议旨在帮助您形成可以有效处理的bug报告。没有人被要求遵循它们，但这样做往往对每个人都有利。
我们不能保证立即修复所有错误。如果漏洞是明显的、严重的，或者影响了很多用户，那么很有可能有人会调查它。我们也可能会告诉你更新到一个新的版本，看看是否有错误发生。或者，我们可能会决定，在我们可能计划的一些重大重写完成之前，无法修复该错误。或者可能这太难了，议程上还有更重要的事情。如果您需要帮助，立即考虑获得商业支持合同。
### 5.1.识别错误
在您报告错误之前，请阅读并重新阅读文档，以验证您是否能够真正做到您正在尝试的任何事情。如果文件中不清楚您是否可以做某事，请也报告；这是文档中的一个bug。如果结果表明一个程序做了与文档中所说的不同的事情，那就是一个bug。这可能包括但不限于以下情况：
- 程序终止时会出现致命信号或操作系统错误消息，指出程序中存在问题。（一个反例可能是“磁盘已满”消息，因为您必须自己修复它。）
- 对于任何给定的输入，程序都会产生错误的输出。
- 程序拒绝接受有效输入（如文档中所定义）。
- 程序在没有通知或错误消息的情况下接受无效输入。但请记住，你对无效输入的看法可能是我们对传统做法的扩展或兼容性的看法。
- PostgreSQL无法在支持的平台上按照说明编译、构建或安装。
这里的“程序”指的是任何可执行文件，而不仅仅是后端进程。
速度慢或占用资源不一定是个问题。阅读文档或在邮件列表中寻求帮助以优化应用程序。不遵守SQL标准也不一定是一个bug，除非明确声明符合特定功能。
在继续之前，请查看待办事项列表和常见问题解答，看看您的错误是否已经被发现。如果您无法解码待办事项列表上的信息，请报告您的问题。我们至少可以把待办事项清单弄清楚。
### 5.2.报告什么
关于bug报告，要记住的最重要的事情是陈述所有事实，并且只陈述事实。不要猜测你认为哪里出了问题，“它似乎在做什么”，或者程序的哪个部分有错误。如果您不熟悉实现，您可能会猜错，对我们一点帮助都没有。即使你是，受过教育的解释是对事实的极好补充，但不能替代事实。如果我们要修复这个错误，我们仍然必须先看到它发生在我们自己身上。报告赤裸裸的事实相对简单（你可能可以从屏幕上复制并粘贴它们），但往往重要的细节被忽略，因为有人认为这无关紧要，或者报告无论如何都会被理解。
每个错误报告中应包含以下内容：
- 步骤的确切顺序*从项目启动开始*这是重现问题的必要条件。这应该是自足的；光寄一封信是不够的`选择`没有前面的语句`创建表格`和`插入`语句，如果输出应取决于表中的数据。我们没有时间对您的数据库模式进行反向工程，如果我们应该自己生成数据，我们可能会错过这个问题。
针对SQL相关问题的测试用例的最佳格式是一个可以通过显示问题的psql前端运行的文件。（一定不要在你的房间里放任何东西。）`~/.psqlrc`启动文件。）创建此文件的一个简单方法是使用pg_dump可转储设置场景所需的表声明和数据，然后添加问题查询。我们鼓励您尽量缩小示例的大小，但这并不是绝对必要的。如果这个错误是可复制的，我们会发现它的任何一种方式。
如果您的应用程序使用了其他一些客户端接口，比如PHP，那么请尝试隔离有问题的查询。我们可能不会设置web服务器来重现您的问题。在任何情况下，请记住提供准确的输入文件；不要猜测问题发生在“大文件”或“中型数据库”等，因为这些信息太不精确，无法使用。
- 你得到的输出。请不要说它“不工作”或“崩溃”。如果有错误信息，即使你不明白，也要显示出来。如果程序因操作系统错误而终止，请说明是哪个。如果什么都没发生，就说出来。即使测试用例的结果是程序崩溃或其他明显的情况，它也可能不会在我们的平台上发生。如果可能的话，最简单的方法是从终端复制输出。
### 笔记
如果报告错误消息，请获取最详细的消息形式。在psql中，比如`\设置冗长冗长`预先如果要从服务器日志中提取消息，请设置运行时参数[日志\_错误\_冗长](runtime-config-logging.html#GUC-LOG-ERROR-VERBOSITY)到`冗长的`以便记录所有详细信息。
### 笔记
如果出现致命错误，客户端报告的错误消息可能不包含所有可用信息。请同时查看数据库服务器的日志输出。如果您不保留服务器的日志输出，这将是开始这样做的好时机。
- 你期望的输出是非常重要的。如果你只是写“这个命令给了我那个输出。”或者“这不是我所期望的。”，我们可能会自己运行它，扫描输出，然后认为它看起来不错，而且正是我们所期望的。我们不应该花费时间来解码命令背后的确切语义。尤其不要仅仅说“这不是SQL所说的/Oracle所做的”从SQL中挖掘出正确的行为并不是一件有趣的事情，我们也不知道其他所有关系数据库的行为。（如果您的问题是程序崩溃，您显然可以忽略此项。）
- 任何命令行选项和其他启动选项，包括从默认设置更改的任何相关环境变量或配置文件。请再次提供准确信息。如果您使用的是在引导时启动数据库服务器的预打包发行版，那么您应该尝试了解如何做到这一点。
- 任何与安装说明不同的操作。
- PostgreSQL版本。您可以运行该命令`选择version（）；`查找所连接服务器的版本。大多数可执行程序也支持`--版本`选项至少`博士后版`和`psql——版本`应该有用。如果功能或选项不存在，那么您的版本已经足够旧，可以进行升级。如果你运行一个预打包的版本，比如RPM，那么就这么说，包括包中可能存在的任何subversion。如果您谈论的是Git快照，请提及它，包括提交散列。
如果您的版本早于14.2，我们几乎肯定会告诉您升级。每个新版本中都有许多错误修复和改进，因此很可能您在较旧版本的PostgreSQL中遇到的错误已经修复。我们只能为使用较旧版本PostgreSQL的网站提供有限的支持；如果你需要更多我们能提供的，考虑获得商业支持合同。
- 平台信息。这包括内核名称和版本、C库、处理器、内存信息等。在大多数情况下，报告供应商和版本就足够了，但不要假设每个人都知道“Debian”到底包含什么，或者每个人都在x86上运行\_64.如果您有安装问题，那么关于机器上的工具链（编译器、make等）的信息也是必要的。
如果你的错误报告变得相当冗长，不要害怕。这是生活中的事实。第一次报道一切比我们从你身上挤出事实来要好。另一方面，如果你的输入文件很大，可以先询问是否有人有兴趣调查。这里有一个[文章](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html)这概括了更多关于报告bug的提示。
不要把所有的时间都花在找出输入中的哪些变化会让问题消失。这可能无助于解决问题。如果事实证明该漏洞无法立即修复，您仍有时间查找并分享您的工作。此外，再次强调，不要浪费时间猜测错误存在的原因。我们很快就会发现。
编写错误报告时，请避免混淆术语。整个软件包被称为“PostgreSQL”，有时简称为“Postgres”。如果你特别谈论后端进程，请提及这一点，不要只说“PostgreSQL崩溃”。单个后端进程的崩溃与父“postgres”进程的崩溃截然不同；请不要说“服务器崩溃”，当你的意思是单个后端进程崩溃时，反之亦然。此外，客户端程序（如交互式前端“psql”）与后端完全分离。请尽量具体说明问题是在客户端还是服务器端。
### 5.3.在哪里报告错误
通常，将错误报告发送到`<[pgsql-bugs@lists.postgresql.org]（mailto:pgsql）-bugs@lists.postgresql.org)>`。我们要求您在电子邮件中使用描述性主题，可能是错误消息的一部分。
另一种方法是填写项目网站上的bug report web表单[网站](https://www.postgresql.org/).以这种方式输入错误报告会将其邮寄至`<[pgsql-bugs@lists.postgresql.org]（mailto:pgsql）-bugs@lists.postgresql.org)>`邮件列表。
如果你的错误报告有安全隐患，并且你不希望它在公共档案中立即可见，不要将其发送给`pgsql错误`.安全问题可以私下报告给`<[security@postgresql.org]（邮寄至：security@postgresql.org)>`.
不要向任何用户邮件列表发送错误报告，例如`<[pgsql-sql@lists.postgresql.org]（mailto:pgsql）-sql@lists.postgresql.org)>`或`<[pgsql-general@lists.postgresql.org]（mailto:pgsql）-general@lists.postgresql.org)>`。这些邮件列表用于回答用户问题，用户通常不希望收到错误报告。更重要的是，他们不太可能解决这些问题。
还有，请*不*向开发者的邮件列表发送报告`<[pgsql-hackers@lists.postgresql.org]（mailto:pgsql）-hackers@lists.postgresql.org)>`。此列表用于讨论PostgreSQL的开发，如果我们能将错误报告分开，那就太好了。我们可能会选择就您的错误报告进行讨论`pgsql黑客`，如果问题需要更多检查。
如果您对文档有问题，最好在文档邮寄列表中报告`<[pgsql-docs@lists.postgresql.org]（mailto:pgsql）-docs@lists.postgresql.org)>`.请具体说明您对文件的哪一部分不满意。
如果您的缺陷是在不受支持的平台上的可移植性问题，请发送邮件至`<[pgsql-hackers@lists.postgresql.org]（mailto:pgsql）-hackers@lists.postgresql.org)>`，所以我们（和你们）可以将PostgreSQL移植到你们的平台上。
### 笔记
由于到处都是令人遗憾的垃圾邮件，除非你订阅了，否则以上所有列表都将被删除。这意味着在发送电子邮件之前会有一些延迟。如果您想订阅这些列表，请访问请示。