# 5.漏洞报告指南

5.1. 识别错误

5.2. 报告什么

5.3. 在哪里报告错误

当你在PostgreSQL中发现一个bug时,我们想听听。您的错误报告在使PostgreSQL更可靠方面发挥了重要作用,因为即使非常小心也不能保证PostgreSQL的每个部分在任何情况下都能在每个平台上工作。

以下建议旨在帮助您形成可以有效处理的bug报告。没有人被要求遵循它们,但这样做往往对每个人都有利。

我们不能保证立即修复所有错误。如果漏洞是明显的、严重的,或者影响了很多用户,那么很有可能有人会调查它。我们也可能会告诉你更新到一个新的版本,看看是否有错误发生。或者,我们可能会决定,在我们可能计划的一些重大重写完成之前,无法修复该错误。或者可能这太难了,议程上还有更重要的事情。如果您需要帮助,立即考虑获得商业支持合同。

# 5.1.识别错误

在您报告错误之前,请阅读并重新阅读文档,以验证您是否能够真正做到您正在尝试的任何事情。如果文件中不清楚您是否可以做某事,请也报告;这是文档中的一个bug。如果结果表明一个程序做了与文档中所说的不同的事情,那就是一个bug。这可能包括但不限于以下情况:

  • 程序终止时会出现致命信号或操作系统错误消息,指出程序中存在问题。(一个反例可能是“磁盘已满”消息,因为您必须自己修复它。)

  • 对于任何给定的输入,程序都会产生错误的输出。

  • 程序拒绝接受有效输入(如文档中所定义)。

  • 程序在没有通知或错误消息的情况下接受无效输入。但请记住,你对无效输入的看法可能是我们对传统做法的扩展或兼容性的看法。

  • PostgreSQL无法在支持的平台上按照说明编译、构建或安装。

    这里的“程序”指的是任何可执行文件,而不仅仅是后端进程。

    速度慢或占用资源不一定是个问题。阅读文档或在邮件列表中寻求帮助以优化应用程序。不遵守SQL标准也不一定是一个bug,除非明确声明符合特定功能。

    在继续之前,请查看待办事项列表和常见问题解答,看看您的错误是否已经被发现。如果您无法解码待办事项列表上的信息,请报告您的问题。我们至少可以把待办事项清单弄清楚。

# 5.2.报告什么

关于bug报告,要记住的最重要的事情是陈述所有事实,并且只陈述事实。不要猜测你认为哪里出了问题,“它似乎在做什么”,或者程序的哪个部分有错误。如果您不熟悉实现,您可能会猜错,对我们一点帮助都没有。即使你是,受过教育的解释是对事实的极好补充,但不能替代事实。如果我们要修复这个错误,我们仍然必须先看到它发生在我们自己身上。报告赤裸裸的事实相对简单(你可能可以从屏幕上复制并粘贴它们),但往往重要的细节被忽略,因为有人认为这无关紧要,或者报告无论如何都会被理解。

每个错误报告中应包含以下内容:

  • 步骤的确切顺序从项目启动开始这是重现问题的必要条件。这应该是自足的;光寄一封信是不够的选择没有前面的语句创建表格插入语句,如果输出应取决于表中的数据。我们没有时间对您的数据库模式进行反向工程,如果我们应该自己生成数据,我们可能会错过这个问题。

    针对SQL相关问题的测试用例的最佳格式是一个可以通过显示问题的psql前端运行的文件。(一定不要在你的房间里放任何东西。)~/.psqlrc启动文件。)创建此文件的一个简单方法是使用pg_dump可转储设置场景所需的表声明和数据,然后添加问题查询。我们鼓励您尽量缩小示例的大小,但这并不是绝对必要的。如果这个错误是可复制的,我们会发现它的任何一种方式。

    如果您的应用程序使用了其他一些客户端接口,比如PHP,那么请尝试隔离有问题的查询。我们可能不会设置web服务器来重现您的问题。在任何情况下,请记住提供准确的输入文件;不要猜测问题发生在“大文件”或“中型数据库”等,因为这些信息太不精确,无法使用。

  • 你得到的输出。请不要说它“不工作”或“崩溃”。如果有错误信息,即使你不明白,也要显示出来。如果程序因操作系统错误而终止,请说明是哪个。如果什么都没发生,就说出来。即使测试用例的结果是程序崩溃或其他明显的情况,它也可能不会在我们的平台上发生。如果可能的话,最简单的方法是从终端复制输出。

    # 笔记

    如果报告错误消息,请获取最详细的消息形式。在psql中,比如\设置冗长冗长预先如果要从服务器日志中提取消息,请设置运行时参数日志_错误_冗长冗长的以便记录所有详细信息。

    # 笔记

    如果出现致命错误,客户端报告的错误消息可能不包含所有可用信息。请同时查看数据库服务器的日志输出。如果您不保留服务器的日志输出,这将是开始这样做的好时机。

  • 你期望的输出是非常重要的。如果你只是写“这个命令给了我那个输出。”或者“这不是我所期望的。”,我们可能会自己运行它,扫描输出,然后认为它看起来不错,而且正是我们所期望的。我们不应该花费时间来解码命令背后的确切语义。尤其不要仅仅说“这不是SQL所说的/Oracle所做的”从SQL中挖掘出正确的行为并不是一件有趣的事情,我们也不知道其他所有关系数据库的行为。(如果您的问题是程序崩溃,您显然可以忽略此项。)

  • 任何命令行选项和其他启动选项,包括从默认设置更改的任何相关环境变量或配置文件。请再次提供准确信息。如果您使用的是在引导时启动数据库服务器的预打包发行版,那么您应该尝试了解如何做到这一点。

  • 任何与安装说明不同的操作。

  • PostgreSQL版本。您可以运行该命令选择version();查找所连接服务器的版本。大多数可执行程序也支持--版本选项至少博士后版psql——版本应该有用。如果功能或选项不存在,那么您的版本已经足够旧,可以进行升级。如果你运行一个预打包的版本,比如RPM,那么就这么说,包括包中可能存在的任何subversion。如果您谈论的是Git快照,请提及它,包括提交散列。

    如果您的版本早于14.2,我们几乎肯定会告诉您升级。每个新版本中都有许多错误修复和改进,因此很可能您在较旧版本的PostgreSQL中遇到的错误已经修复。我们只能为使用较旧版本PostgreSQL的网站提供有限的支持;如果你需要更多我们能提供的,考虑获得商业支持合同。

  • 平台信息。这包括内核名称和版本、C库、处理器、内存信息等。在大多数情况下,报告供应商和版本就足够了,但不要假设每个人都知道“Debian”到底包含什么,或者每个人都在x86上运行_64.如果您有安装问题,那么关于机器上的工具链(编译器、make等)的信息也是必要的。

    如果你的错误报告变得相当冗长,不要害怕。这是生活中的事实。第一次报道一切比我们从你身上挤出事实来要好。另一方面,如果你的输入文件很大,可以先询问是否有人有兴趣调查。这里有一个文章 (opens new window)这概括了更多关于报告bug的提示。

    不要把所有的时间都花在找出输入中的哪些变化会让问题消失。这可能无助于解决问题。如果事实证明该漏洞无法立即修复,您仍有时间查找并分享您的工作。此外,再次强调,不要浪费时间猜测错误存在的原因。我们很快就会发现。

    编写错误报告时,请避免混淆术语。整个软件包被称为“PostgreSQL”,有时简称为“Postgres”。如果你特别谈论后端进程,请提及这一点,不要只说“PostgreSQL崩溃”。单个后端进程的崩溃与父“postgres”进程的崩溃截然不同;请不要说“服务器崩溃”,当你的意思是单个后端进程崩溃时,反之亦然。此外,客户端程序(如交互式前端“psql”)与后端完全分离。请尽量具体说明问题是在客户端还是服务器端。

# 5.3.在哪里报告错误

通常,将错误报告发送到<[pgsql-bugs@lists.postgresql.org](mailto:pgsql)-bugs@lists.postgresql.org)>。我们要求您在电子邮件中使用描述性主题,可能是错误消息的一部分。

另一种方法是填写项目网站上的bug report web表单网站 (opens new window).以这种方式输入错误报告会将其邮寄至<[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移植到你们的平台上。

# 笔记

由于到处都是令人遗憾的垃圾邮件,除非你订阅了,否则以上所有列表都将被删除。这意味着在发送电子邮件之前会有一些延迟。如果您想订阅这些列表,请访问https://lists.postgresql.org/ (opens new window)请示。