DuckDB PostgreSQL 扩展中的 EXPLAIN 语句资源泄漏问题分析

在 PostgreSQL 数据库中使用 DuckDB 扩展执行 EXPLAIN 语句时，发现了一个严重的资源管理问题。当用户启用 DuckDB 执行模式后，执行包含表扫描的 EXPLAIN 查询会导致关系缓存泄漏，并在进程退出时引发段错误(Segmentation fault)。

问题现象

当用户执行以下操作序列时：

1. 启用 DuckDB 执行模式
2. 创建测试表
3. 对该表执行 EXPLAIN 查询

系统会输出关系缓存泄漏警告，并在进程退出时产生段错误。从错误日志可以看到，服务器进程被信号 11(SIGSEGV)终止。

技术分析

这个问题涉及 PostgreSQL 扩展开发中的两个关键方面：

1. 资源管理机制：PostgreSQL 使用资源所有者(ResourceOwner)来跟踪和管理各种资源，包括关系缓存。当资源未被正确释放时，系统会检测到并发出警告。

2. DuckDB 执行计划处理：在 DuckDB 扩展中，EXPLAIN 语句的处理与常规查询执行存在差异。常规查询会完整消费查询结果，而 EXPLAIN 只获取一次结果就停止。

深入分析发现，问题根源在于 PostgresTable 类的析构函数没有被正确调用。在常规查询扫描(Scan)回调中，系统会持续调用 Fetch() 直到结果耗尽，这会触发正确的资源清理。但在 EXPLAIN 处理中，只调用了一次 Fetch()，导致相关资源未被释放。

解决方案

开发团队提出了两种互补的解决方案：

1. 完整消费查询结果：修改 EXPLAIN 处理逻辑，像常规查询一样完整消费结果集，确保所有资源被正确释放。

2. 事务回滚处理：在 PostgresTransactionManager 的"回滚"阶段显式清理残留的表资源，这可以处理其他可能的资源泄漏情况。

第一种方案直接解决了当前问题，而第二种方案提供了更全面的资源管理保障，特别是在未来支持写入操作时更为重要。例如，EXPLAIN ANALYZE INSERT 这样的语句需要确保在回滚时所有资源都能被正确清理。

最佳实践建议

对于 PostgreSQL 扩展开发者，这个案例提供了几个重要经验：

1. 资源生命周期管理：必须确保所有分配的资源都有明确的释放点，特别是在异常路径上。

2. 执行模式差异处理：对于不同的执行模式(如常规查询和EXPLAIN)，需要确保资源管理策略的一致性。

3. 事务安全：任何可能涉及事务的操作，都需要考虑回滚场景下的资源清理。

这个问题展示了数据库扩展开发中资源管理的复杂性，也体现了 DuckDB 团队对代码质量的严格要求。通过这种问题的分析和解决，可以提升整个扩展的稳定性和可靠性。