4paradigm / 4paradigm/OpenMLDB

SQL Engine assumes all the pointers are valid during the computation period while it is not always true

未关闭
#2,944 1 条评论 0 个 reaction 已指派 2 人 已被 @aceforeverd 认领 在 GitHub 查看
bug high-priority
主要语言
C++
星标
1.7k
派生
331
平均合并
12 天 12 小时
30 天内合并 PR
1

描述

**Bug Description**
SQL Engine assumes all the pointers are valid during the computation period,
while it is not true in the storage engine.

For example,
for `*_cate` (see issue #2931), sql engine assumes that the `StringRef`s are valid during the whole computation, while in the `Iterator` implementation (see pr #2939), the `value` will become invalid/freed after the next call of `Next`.
- `FullTableIterator`: fixed in #2939, guarantee the `value` is valid in the whole life cycle of `Iterator`
- `RemoteWindowIterator`: as `sliding window` copies the rows, we didn't change the current behaviour for now
- For local `Iterator`, we haven't fixed it for now.

**Expected Behavior**
We have to work out a good solution between SQL engine and storage engine to make them have the same assumption.

**Relation Case**

**Steps to Reproduce**

1.
2.
3.
4.

贡献指南

打开贡献指南

调研方向

The issue references SQL engine and storage engine pointer validity, specifically StringRef in *_cate functions. Examine the Iterator implementations (FullTableIterator, RemoteWindowIterator, local Iterator) in the storage engine. Look at the SQL engine's assumption that pointers remain valid. Start by reading the code around issue #2931 and PR #2939 to understand the context. Determine what a 'good solution' for pointer lifetime coordination between the two subsystems would entail.

由索引模型根据 Issue 内容生成。

评估

技术栈
sql
领域
backend, databases
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。