ManticoreSearch表达式解析器线程栈限制问题分析

问题背景

在ManticoreSearch数据库系统中，用户发现了一个关于表达式解析器线程栈限制的有趣问题。当执行包含大量嵌套IF条件的复杂SQL查询时，系统会抛出"query expressions too complex"错误，提示需要增加thread_stack参数值。然而即使用户通过SET命令调整了会话级别的thread_stack参数，问题依然存在。

问题现象

测试用例展示了一个包含500层嵌套IF条件的极端SQL查询。这个查询结构如下：

SELECT SINT(IF(a IN(1,2),20, IF(a IN(2,3),30, ... IF(a IN(500,501),5010,0)...)) as b FROM demo;

在默认配置下执行时，系统会报错提示需要将thread_stack设置为至少1418K。令人困惑的是，即使用户通过SET thread_stack = 10000000将会话级别的线程栈大小增加到10MB，错误仍然出现。

技术分析

线程栈管理机制

ManticoreSearch中线程栈大小的管理分为两个层次：

1. 实例级(全局)配置：通过配置文件或VIP连接的SET GLOBAL命令设置，影响整个数据库实例
2. 会话级配置：通过普通连接的SET命令设置，仅影响当前会话

问题根源

经过分析，问题的根本原因在于表达式解析器的实现存在不一致性。表达式解析器错误地直接引用了全局实例级的线程栈限制，而忽略了会话级别的设置。这种设计缺陷导致：

1. 会话级别的thread_stack调整对表达式解析无效
2. 用户无法通过会话设置来解决复杂表达式解析的栈空间问题
3. 系统行为与用户预期不符

影响范围

这个问题在调试构建(Debug Build)中更容易重现，因为调试版本通常需要更大的栈空间。在发布版本(Release Build)中，由于优化减少了栈帧大小，需要更复杂的查询(如数千层嵌套)才能触发相同问题。

解决方案与修复

修复方案的核心是确保表达式解析器正确使用会话级别的线程栈限制。具体包括：

1. 修改表达式解析器实现，使其优先使用会话级配置
2. 当会话级未设置时，回退到实例级配置
3. 保持向后兼容性，不影响现有配置行为

测试验证

为了验证修复效果，可以使用以下bash脚本生成测试查询：

#!/bin/bash
N=500
S="SELECT SINT("
I=1
for a in `seq 1 $N`; do
  S="${S}IF(a IN($I"
  I=$((I+1))
  S="${S},$I),${I}0, "
done
S="${S}0"
for a in `seq 1 $N`; do
  S="${S})"
done
S="$S) as b FROM demo;"
echo $S

修复后，即使用户仅通过会话级SET命令增加thread_stack，复杂查询也能正常执行。

总结

这个问题的解决不仅修复了一个具体的技术缺陷，更重要的是统一了ManticoreSearch中资源限制的管理方式。它确保了：

1. 配置行为的一致性
2. 用户预期的可预测性
3. 系统资源的灵活管理能力

对于需要处理极端复杂查询的用户，现在可以通过会话级设置临时增加资源，而不必修改全局配置或重启服务。这种改进显著提升了系统的可用性和灵活性。