pg_duckdb扩展中并行查询导致PostgreSQL服务器崩溃问题分析

在PostgreSQL数据库系统中使用pg_duckdb扩展时，开发人员发现了一个严重的稳定性问题：当执行包含模运算条件的COUNT查询时，PostgreSQL服务器会意外崩溃。这个问题出现在启用了多线程查询的特定配置下。

问题现象

当用户创建一个测试表并插入大量数据后，执行类似SELECT COUNT(*) FROM t WHERE a % 10 = 0的查询时，PostgreSQL服务器会立即崩溃。崩溃时的调用栈显示问题发生在缓冲区管理器和MVCC可见性检查的交互过程中。

技术背景

pg_duckdb是一个允许在PostgreSQL中执行DuckDB查询的扩展。DuckDB是一个高性能的分析型数据库系统，它支持多线程查询执行。当启用duckdb.execution选项时，查询会由DuckDB引擎处理，但仍需要访问PostgreSQL的存储层。

根本原因分析

从崩溃堆栈可以看出，问题发生在以下关键路径：

1. DuckDB的多线程查询执行器启动多个工作线程
2. 这些线程并发访问PostgreSQL的堆表数据
3. 在MVCC可见性检查过程中，触发了缓冲区脏标记操作
4. 系统断言失败，因为线程没有持有必要的轻量级锁(LWLock)

这个问题揭示了pg_duckdb扩展与PostgreSQL存储引擎交互时的一个关键缺陷：DuckDB的多线程执行模型与PostgreSQL的缓冲区访问协议存在不兼容。PostgreSQL要求对缓冲区的修改必须持有适当的锁，而DuckDB的工作线程在没有获取这些锁的情况下尝试修改缓冲区。

解决方案

该问题已在pg_duckdb的最新版本中修复。修复方案主要涉及：

1. 确保所有访问PostgreSQL存储的DuckDB线程都正确获取必要的锁
2. 修改缓冲区访问协议，使其与PostgreSQL的并发控制机制兼容
3. 在关键路径添加适当的锁获取和释放逻辑

最佳实践建议

对于使用pg_duckdb扩展的用户，建议：

1. 及时更新到包含此修复的最新版本
2. 在多线程查询场景下，仔细测试与PostgreSQL存储层的交互
3. 监控系统日志，及时发现任何潜在的并发控制问题
4. 对于关键业务系统，考虑在测试环境中充分验证后再部署到生产环境

这个问题的修复显著提高了pg_duckdb扩展在复杂查询场景下的稳定性，为混合使用PostgreSQL和DuckDB功能的用户提供了更好的体验。