程序以致命信号或会指向程序问题的操作系统错误消息终止。（一个反例可能是“磁盘已满”消息，因为您必须自己修复它。）

对于任何给定的输入，程序生成了错误的输出。

程序拒绝接受有效输入（如文档中所定义）。

程序接受无效输入，却不发出任何通知或错误消息。但请记住，您认为的无效输入可能是我们认为的扩展或与传统做法的兼容性。

PostgreSQL未能根据受支持平台上的说明进行编译、构建或安装。

重现问题必要的 从程序启动 开始的步骤的准确顺序。它应自包含；仅仅发送一个光秃秃的 SELECT 语句是不够的，没有前面的 CREATE TABLE 和 INSERT 语句，如果输出应该取决于表中的数据。我们没有时间对您的数据库模式进行逆向工程，并且如果我们应该自己编造数据，我们很可能会错过问题。

与 SQL 相关的问题的最佳测试用例格式是可以通过 psql 前端运行的文件，该文件展示了问题。（确保您的 ~/.psqlrc 启动文件中没有任何内容。）创建一个此文件的一个简单方法是使用 pg_dump 导出设置场景所需的表声明和数据，然后添加问题查询。我们鼓励您尽可能减小示例的大小，但这并不是绝对必要的。如果错误可以重现，我们会找到解决方法。

如果您的应用程序使用其他一些客户端界面，例如 PHP，请尝试隔离含有问题的查询。我们不太可能设置一个 Web 服务器来重现您的问题。无论如何，请务必提供准确的输入文件；不要根据 “大文件” 或 “中型数据库” 等猜测问题，因为这些信息太不准确，无法使用。

得到的输出。请不要说 “不起作用” 或 “崩溃了”。如果有错误消息，请显示出来，即使你无法理解。如果程序因操作系统错误而终止，请说明具体是什么错误。如果没有任何结果，也请说明。即使测试用例的结果是程序崩溃或其他显而易见的问题，但可能不会在我们的平台上发生。如果可能的话，最简单的方法是从终端复制输出。

说明期望的输出非常重要。如果你仅仅写 “此命令给我该输出。” 或 “这不是我期望的。”，我们可能会自己运行它，扫描输出，并认为它看起来还可以，完全符合预期。我们不应该花时间解码命令背后的确切语义。特别是不要仅仅说 “这不是 SQL/Oracle 所说的/做的。” 从中挖掘出正确的行为SQL并不是一件有趣的事情，我们也不知道其他所有关系数据库的行为。(如果你的问题是程序崩溃，显然可以省略此项。)

有任何命令行选项和其他启动选项，包括任何与默认值不同的相关环境变量或配置文件。同样，请提供确切的信息。如果你正在使用预先打包的发行版，它在启动时启动数据库服务器，你应该设法找出如何做到这一点。

在安装说明中，所做的任何与众不同之处。

PostgreSQL 版本。你可以运行命令 SELECT version(); 来找出你连接的服务器版本。大多数可执行程序还支持一个 --version 选项；至少 postgres --version 和 psql --version 应该能工作。如果函数或选项不存在，则你的版本太旧了，需要升级。如果你运行的是预打包版本，例如 RPM，请说出来，包括包可能拥有的任何子版本。如果你正在谈论 Git 快照，请提及它，包括提交哈希值。

如果你的版本低于 17.1，我们几乎可以肯定你需要升级。每个新版本都有众多 bug 修复和改进，因此在旧版本 PostgreSQL 中遇到的 bug 可能已修复。对于那些正在使用旧版本 PostgreSQL 的网站，我们只能提供有限的支持；如果你要求的超出我们可以提供的支持范围，请考虑购买商用支持合同。

平台信息。这包括内核名称和版本、C 库、处理器、内存信息等。在大多数情况下，报告供货商和版本就足够了，但不要假设每个人都知道 “Debian” 确切包含什么，或者每个人都运行 x86_64。如果你在安装时遇到问题，还必须提供有关机器上的工具链的信息（编译器、make 等）。