pg_duckdb项目中的PostgreSQL JSONB与数组类型内存泄漏问题分析

问题背景

在pg_duckdb项目中，当扫描包含JSONB或数组类型的PostgreSQL表时，会出现内存持续增长的问题。这个问题源于PostgreSQL内部函数的内存管理机制与DuckDB的内存管理方式存在差异。

技术细节

PostgreSQL在处理JSONB和数组类型时，会使用palloc函数分配内存。这些函数包括：

• JsonbToCString：用于将JSONB数据转换为字符串
• deconstruct_array：用于解析数组类型数据

这些函数分配的内存属于PostgreSQL的内存上下文(MemoryContext)系统，而pg_duckdb在执行查询时没有及时释放这些内存，导致内存泄漏。在PostgreSQL中，这些内存通常会在查询执行结束时由ExecutorState统一释放，但在pg_duckdb的场景下，这种延迟释放会导致内存持续增长。

问题复现

可以通过以下SQL语句复现这个问题：

-- JSONB类型内存泄漏
CREATE TABLE j1(c jsonb);
INSERT INTO j1 SELECT '{"large_key_name": 1}'::jsonb FROM generate_series(1, 10000000);
SELECT * FROM j1 ORDER BY 1 LIMIT 1;

-- 数组类型内存泄漏
CREATE TABLE a1(c text[]);
INSERT INTO a1 SELECT array['large_string_element'] FROM generate_series(1, 10000000);
SELECT * FROM a1 ORDER BY 1 LIMIT 1;

解决方案探讨

项目维护者提出了两种解决方案：

1. 自定义实现方案：为pg_duckdb重新实现JsonbToCString和deconstruct_array函数。这种方法虽然能彻底解决问题，但实现复杂度高，且可能引入兼容性问题。

2. 内存上下文管理方案：在调用这些函数前切换到专用的内存上下文，然后定期重置该上下文来回收内存。这种方法更优雅，且与PostgreSQL的内存管理机制更契合。

经过讨论，项目团队决定采用第二种方案，因为它：

• 维护成本低
• 与现有PostgreSQL架构兼容
• 性能影响可控

实现优化

在具体实现上，开发者需要考虑以下优化点：

1. 内存上下文创建时机：不应为每次转换创建新的内存上下文，这会导致性能下降。建议在查询开始时创建，查询结束时销毁。

2. 内存回收策略：可以设置内存阈值(如8MB)，当内存使用超过阈值时自动重置上下文，避免内存无限增长。

3. 上下文层级关系：应将专用内存上下文作为当前内存上下文的子上下文，确保它能随查询结束自动释放，避免长期内存占用。

总结

pg_duckdb在处理PostgreSQL复杂数据类型时的内存泄漏问题，反映了不同数据库系统内存管理机制的差异。通过合理利用PostgreSQL的内存上下文系统，可以在保持兼容性的同时有效解决内存泄漏问题。这种解决方案不仅适用于JSONB和数组类型，也可为其他类似场景提供参考。