让 PostgreSQL Meson 测试失败输出可操作：从多次补丁迭代到已合并

引言

这封 pgsql-hackers 讨论串聚焦一个高频痛点：回归测试或 TAP 测试失败时，默认输出往往不足以直接定位原因，开发者还要手动翻 regression.diffs、日志文件甚至 CI 目录结构。该补丁集的目标是让失败信息在本地和 CI 中都更“开箱即用”，把关键诊断直接放进 TAP 输出。

技术分析

补丁集做了什么

到 v4/v5 时，该系列演进为 5 个补丁，覆盖 pg_regress 与 Perl TAP 辅助库：

pg_regress：把 regression.diffs 的前几段内容直接输出为诊断信息。
TAP 命令辅助：命令失败时打印命令行、stdout、stderr。
TAP 异常处理：辅助代码 die 时输出更有意义的诊断。
Perl 辅助库清理：大量 die 改为 croak，让报错定位到测试脚本调用点。
对 pg_upgrade 某个 TAP 测试的输出进一步简化，减少噪声。

版本演进（v1 到 v5）

v1：起步是 Meson 场景下的可读性改进，含 4 个核心补丁。
v2：响应评审意见，尤其是将局部修复扩展为更系统的 croak 改造。
v3：继续打磨输出格式和细节处理。
v4：新增第 5 个补丁，优化 pg_upgrade 测试输出可读性。
v5：补全文档化元信息并做收敛，进入可提交状态。

其中两个关键技术细化点：

pg_regress 增加了更细粒度的诊断输出标记，用于稳定地输出多行 TAP 诊断内容。
TAP 命令输出从“全量倾倒”改为“有界输出”（前后片段），既保留上下文，又避免日志淹没。

SQL 示例

这个线程本质是测试基础设施改进，而不是 SQL 新语法功能。不过讨论中反复出现了一个典型失败场景：TAP 中执行了错误 SQL，过去很难在 CI 输出里快速看清。下面是代表性示例：

-- 线程中讨论过的 TAP 失败场景示例 SQL。
CREATE TABLE sysuser_data (n) AS
SELECT NULL FROM generate_series(1, 10);

-- 故意写错引号，触发错误并观察诊断输出。
GRANT ALL ON sysuser_data TO scram_role ';

另一类受益场景是回归测试结果不一致时，可直接从输出中看到 diff 线索，减少来回跳转：

-- 代表性的回归测试差异排查上下文。
SELECT a, b
FROM (VALUES (1, 'one'), (2, 'two')) AS t(a, b)
ORDER BY a DESC;

这些 SQL 主要用于说明诊断可读性改进；是否能复现取决于带补丁的测试工具链与测试环境，而非已发布版本新增 SQL 功能。

社区观察

评审过程把“局部可用”推进到“体系化可维护”：

对重复诊断逻辑的意见，推动了辅助函数抽象。
对 IPC::Run 潜在卡死的担忧，促成了更安全的命令执行路径。
“把 die 换成 croak”的建议显著改善了错误定位质量。
提交前还围绕 commit message 形态与元信息做了多轮打磨。

这也体现了 PostgreSQL 社区的一贯取向：测试基础设施的可观测性提升并非“锦上添花”，而是直接影响开发效率和评审吞吐的核心工程工作。

技术细节

线程里讨论并落地的实现重点包括：

为多行 TAP 诊断提供更结构化的输出方式，兼顾可读性与可解析性。
在命令失败路径捕获 stdout/stderr 并输出有界片段。
调整 TAP 辅助代码，降低命令执行挂起风险。
通过 croak 与提交者侧的 @CARP_NOT 调整，让错误回溯更接近 TAP 脚本调用点，而不是深层辅助模块内部。

最终效果不是“输出更多”，而是“输出更有用”，即更快把失败信号转化为可操作的修复线索。

当前状态

该线程从 v1 演进到 v5 后已被提交。提交者在入库时做了小幅整理，包括 @CARP_NOT 的处理，以便 croak() 能更准确指向 TAP 脚本调用方。提交后仍有针对个别行为偏好的后续讨论，但主补丁集已进入主线。

结论

这组改动很好地说明了 PostgreSQL 工程实践中的“杠杆点”：改进失败诊断路径，能显著降低调试与评审成本。通过让 CI 和本地失败输出更自解释，整个社区在处理回归与不稳定测试时都能更快定位问题、推进迭代。

Postgres Weekly, A Hacker’s Digest