DuckDB 1.2.0版本中Parquet读取功能的一个边界条件Bug分析

在DuckDB数据库系统的1.2.0版本中，当用户尝试同时使用schema映射、filename选项和过滤条件来读取Parquet文件时，系统会出现内部错误导致崩溃。这个Bug虽然看起来是特定条件下的边界情况，但它揭示了DuckDB在复杂查询处理流程中的一些潜在问题。

问题现象

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

1. 首先创建一个包含简单序列的Parquet文件
2. 然后使用read_parquet函数读取该文件，同时指定：
   • schema映射（将字段ID映射为列名和类型）
   • filename选项（要求返回文件名信息）
   • WHERE过滤条件

系统会抛出"Attempted to access index 1 within vector of size 1"的内部错误，随后数据库会进入不可用状态，需要重启才能继续使用。

技术背景

DuckDB的Parquet读取功能支持多种高级特性：

• 字段ID映射：允许用户为Parquet文件中的字段指定自定义名称和类型
• 文件名追踪：可以返回每行数据来自哪个文件
• 谓词下推：在读取时应用过滤条件以提高性能

这些功能在单独使用时都能正常工作，但当它们组合在一起时，系统在处理列索引时出现了不一致。

根本原因

通过代码分析，我们发现问题的根源在于：

1. 当启用filename选项时，系统会在结果中添加额外的列来存储文件名信息
2. 但在创建过滤映射(CreateFilterMap)时，系统错误地使用了原始列的数量，而没有考虑这些额外添加的列
3. 这导致系统尝试访问不存在的列索引，触发了断言失败

类似的问题也出现在Delta Lake格式文件的读取中，表明这是一个更普遍的逻辑缺陷，而不仅限于基本Parquet读取功能。

解决方案

修复这个问题的正确方法是确保：

1. 在创建过滤映射时，使用包含所有列（包括filename等系统添加列）的总数
2. 正确处理列索引偏移量，考虑到额外添加的列
3. 在schema映射和实际列访问之间保持一致的索引计算

影响范围

这个Bug影响：

• DuckDB 1.2.0版本
• 使用schema映射、filename选项和过滤条件组合的Parquet查询
• 类似的Delta Lake格式查询

最佳实践

对于用户来说，在等待官方修复的同时可以：

1. 避免同时使用这些功能的组合
2. 考虑将过滤条件移到读取后的步骤中
3. 对于必须使用的情况，可以降级到1.1.0版本

这个案例很好地展示了数据库系统中复杂功能组合时可能出现的边界条件问题，也提醒我们在设计查询执行计划时需要全面考虑各种可能的列操作和转换。