程序因致命信号（fatal signal）或操作系统底层错误提示异常终止，表明程序内部发生了故障（反例是“磁盘空间已满”等系统提示，此类情况属于系统运维层面的资源问题，需自行解决）。

对于任何给定的有效输入，程序产生了错误的输出结果。

程序拒绝接收符合文档规范的合法输入。

程序在面对非法输入时未抛出任何告警或错误提示直接接受。但请注意，你认为的非法输入可能正是社区为了向后兼容或功能扩展所支持的设计。

在官方支持的软硬件平台上，完全按照官方文档指引却无法正常编译、构建或安装 PostgreSQL。

能够复现该问题的完整确切操作序列，必须从程序启动开始算起。该步骤必须具备自闭环性（self-contained）：如果输出结果依赖于数据表中的数据，那么仅发送一个孤立的 SELECT 语句是完全不够的，必须附带前置的 CREATE TABLE 与 INSERT 初始化语句。开发团队没有时间去逆向猜测你的数据库 Schema 设计，如果让我们自行捏造测试数据，很可能无法触发真正的缺陷。

针对 SQL 相关问题，最高效的测试用例格式是提供一个可直接在 psql 命令行前端运行并重现故障的 SQL 脚本文件（请确保你的个人配置文件 ~/.psqlrc 中没有任何会干扰环境的自定义设置）。生成该脚本的简便方法是使用 pg_dump 导出构建复现环境所需的表结构与数据定义，随后在末尾附加引发异常的目标查询。鼓励将用例精简至最小可复现规模，但即便数据稍大也不必过于顾虑，只要故障具备确定复现性，我们就能定位问题根源。

如果你的应用使用的是其他客户端开发接口（例如 PHP、Node.js、Python 等），请尽量在数据库层面分离出有问题的具体 SQL 语句。核心团队通常不会搭建整套 Web 服务器来复现你的应用层代码。无论如何，请务必提供确切的输入数据与环境参数，不要模糊猜测问题发生在“处理大文件”或“中等规模数据库”时，这类不明确的信息对定位问题毫无助益。

你所得到的实际输出结果。请不要只用一句话概括为“系统报错了”或“程序崩溃了”。如果有错误信息，即使你无法理解其含义，也请完整贴出其原始提示。如果程序因操作系统级错误而终止，请指明具体的系统退出代码或信号。如果终端没有任何响应或静默退出，也请如实说明。即使在你的机器上测试用例必定导致崩溃，在开发者的硬件平台上可能表现完全不同。最可靠的方式是直接完整截取终端输出文本。

明确说明你所期望的输出结果，这一点极为关键。如果你仅描述“运行此命令得到了这个输出”或“这不是我期望的结果”，开发者自行运行后很可能会认为输出符合逻辑、正是标准行为。我们不应耗费精力去猜测你每条命令背后的主观意图。尤其请避免简单宣称“SQL 标准不是这样规定的”或“Oracle 不是这样表现的”。从数千页的 SQL 标准中寻找某项边缘行为的权威依据是一项极其耗时的工作，开发团队也无法对市面上所有其他商业数据库的细微差异了如指掌（如果问题属于程序崩溃，此项可直接忽略）。

所使用的任何命令行启动参数、环境变量配置，以及相对于默认配置发生过改动的配置文件内容。请务必提供精确的参数取值。如果你使用的是操作系统发行版预打包的服务，且该服务在系统开机时自动拉起，请说明系统服务具体的启动配置方式。

你在安装、编译或初始化集群时，是否有任何与官方安装文档步骤不一致的操作。

确切的 PostgreSQL 版本号。你可以通过连接数据库后运行 SELECT version(); 查询服务端的完整编译版本信息。绝大多数可执行文件也支持 --version 参数；至少 postgres --version 与 psql --version 应当能够正常输出版本号。如果对应命令不存在该选项，说明当前安装版本过于陈旧，应立刻进行大版本升级。如果你使用的是第三方打包版本（如官方 RPM 或 APT 仓库），请注明完整的软件包全名及子版本号。如果是从 Git 源码编译构建的开发分支，请提供具体的 Commit Hash。

如果所运行的版本早于当前官方支持版本（如 18.6），核心团队通常会建议优先升级。每个新维护版本中都修复了大量历史缺陷，旧版本中遇到的 Bug 很可能在新版本中已被修正。社区对已结束生命周期（EOL）的陈旧版本仅能提供极其有限的排查支持；如需针对过往版本的长期维护，请考虑采购商业支持服务。

操作系统与底层平台信息，包括操作系统内核名称与版本号、C 基础运行库版本、CPU 架构型号以及内存容量等。在绝大多数情况下，指明发行版名称与主次版本号即可，但不要默认所有人都熟悉特定发行版具体集成了哪些组件，也不要预设系统必定运行于 x86_64 架构。如果遇到了编译或构建层面的故障，请附带机器上的基础构建工具链信息（如 GCC/Clang 编译器版本、make 或 meson 版本等）。