[Bug]: create FULLTEXT INDEX on table(has many data) failed

[tom-csf]

Is there an existing issue for the same bug?

• I have checked the existing issues.

Branch Name

main

Commit ID

9a8c097

Other Environment Information

- Hardware parameters:
- OS type:
- Others:

Actual Behavior

Expected Behavior

No response

Steps to Reproduce

1、load tpch 10g data to mo
2、set experimental_fulltext_index=1;
CREATE FULLTEXT INDEX ftidx ON lineitem(l_comment);

Additional information

[tom-csf]

https://shanghai.idc.matrixorigin.cn:30001/explore?panes=%7B%22O2c%22:%7B%22datasource%22:%22loki%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Bnamespace%3D%5C%22mo-chaos-9a8c097-202411102210%5C%22%7D%20%7C%3D%20%60CREATE%20FULLTEXT%20INDEX%20ftidx%20ON%20lineitem%28l_comment%29%60%22,%22queryType%22:%22range%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22loki%22%7D,%22editorMode%22:%22builder%22%7D%5D,%22range%22:%7B%22from%22:%221731293422000%22,%22to%22:%221731293962000%22%7D%7D%7D&schemaVersion=1&orgId=1

[tom-csf]

验证发现 没有完全修复问题：
单cn main分支出现 cn 重启 //log文件已经单独发送给研发
可能是oom 进入pod 发现 mem一直在涨

多cn 2.0-dev分支报错 无cn 重启

https://grafana.ci.matrixorigin.cn/explore?panes=%7B%22njJ%22:%7B%22datasource%22:%22loki%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Bnamespace%3D%5C%22mo-branch-nightly-e9f6396df-20241112%5C%22%7D%20%7C%3D%20%60no%20such%20table%20tpch_10g.__mo_index_secondary_01932380-f024-7658-921f-10bb063ba019%60%22,%22queryType%22:%22range%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22loki%22%7D,%22editorMode%22:%22builder%22%7D%5D,%22range%22:%7B%22from%22:%221731467293000%22,%22to%22:%221731467593000%22%7D%7D%7D&schemaVersion=1&orgId=1

[ouyuanning]

多CN报错的复现方式

select mo_ctl('cn', 'task', 'disable');
drop database if exists db1;
create database db1;
use db1;

set experimental_fulltext_index=1;
drop table if exists t1;
create table t1(a int primary key, b varchar(200));
insert into t1 select result, "test create big fulltext index" from generate_series(3000000) g;  //如果把这里的数据量变小，后面的就不会报错，比如300000
create fulltext index ftidx on t1 (b); //这里会报错，

报错是这个地方

直接原因是601行的判断，进不去。

[aptend]

报错的表 _mo_index_secondary* 没有被创建过，Relation 接口返回找不到表是预期行为。需要关注索引表的创建逻辑

[qingxinhome]

定位分析中

[qingxinhome]

执行创建索引语句时，会有一下步骤：

1. 检查索引表名是否已经存在，如果存在就报错， 如果不存在就执行步骤2
2. 调用txnDatabase.Create()接口方法，在当前事务中创建索引表对应的relation
3. 如果索引表有自增列，自增列表中插入目标表的自增列信息
4. 往索引表中填入数据， 构建insert into select * from语句，通过调用TxnExecutor内部执行器，执行该insert语句
   以上步骤全部成功后，索引即可创建成功

通过日志分析，发现步骤1，步骤2，步骤3均已执行成功，索引表创建成功后，也可以获取对应的relation，但是执行步骤4时失败报错，
也就是说，索引表的表结构创建成功了，但是往索引表中insert数据时报错，
通过日志看到，内部执行器TxnExecutor在运行insert into select的物理计划时， 执行到preinsert算子报错了，
原因是在生成自增列值的过程中无法找到对应的表id， 如下图所示

@ouyuanning @aptend

[aptend]

执行创建索引语句时，会有一下步骤：

1. 检查索引表名是否已经存在，如果存在就报错， 如果不存在就执行步骤2
2. 调用txnDatabase.Create()接口方法，在当前事务中创建索引表对应的relation
3. 如果索引表有自增列，自增列表中插入目标表的自增列信息
4. 往索引表中填入数据， 构建insert into select * from语句，通过调用TxnExecutor内部执行器，执行该insert语句
   以上步骤全部成功后，索引即可创建成功

通过日志分析，发现步骤1，步骤2，步骤3均已执行成功，索引表创建成功后，也可以获取对应的relation，但是执行步骤4时失败报错， 也就是说，索引表的表结构创建成功了，但是往索引表中insert数据时报错， 通过日志看到，内部执行器TxnExecutor在运行insert into select的物理计划时， 执行到preinsert算子报错了， 原因是在生成自增列值的过程中无法找到对应的表id， 如下图所示

第三步插入自增列信息的 txnid 和第四步读取的 txnid 不同，属于不同事务。所以查不到

[jensenojs]

执行创建索引语句时，会有一下步骤：

1. 检查索引表名是否已经存在，如果存在就报错， 如果不存在就执行步骤2
2. 调用txnDatabase.Create()接口方法，在当前事务中创建索引表对应的relation
3. 如果索引表有自增列，自增列表中插入目标表的自增列信息
4. 往索引表中填入数据， 构建insert into select * from语句，通过调用TxnExecutor内部执行器，执行该insert语句
   以上步骤全部成功后，索引即可创建成功

通过日志分析，发现步骤1，步骤2，步骤3均已执行成功，索引表创建成功后，也可以获取对应的relation，但是执行步骤4时失败报错， 也就是说，索引表的表结构创建成功了，但是往索引表中insert数据时报错， 通过日志看到，内部执行器TxnExecutor在运行insert into select的物理计划时， 执行到preinsert算子报错了， 原因是在生成自增列值的过程中无法找到对应的表id， 如下图所示

@ouyuanning @aptend

• CN1上执行到第三步 : 自增列表中插入目标表的自增列信息的时候
  • incr-service将其对应的tableID存在内部的一个map
  • 由于本事务还没有提交, 因此这个tableID(暂名为xxx)通过SQL去查是查不到的, 👇就是喜亮哥日志中显示的, 和原来create fulltext index不一样的事务.

    select col_name, col_index, offset, step from mo_increment_columns where table_id = 272590 order by col_index

• 这个SQL是在CN2上执行的, 现在看原因是insert into select的数据量规模达到一定程度, 所以将一部分的insert的工作分到了CN2上
  • 但由于CN2上的incr-service的map中没有xxx, 所以它只能通过后台SQL去查
  • 且由于CN1上的事务还没有提交, 所以查不到

• mo启动方式

./mo-service -cfg etc/launch-with-proxy/log.toml > log.log & 
./mo-service -cfg etc/launch-with-proxy/tn.toml > tn.log & 
./mo-service -cfg etc/launch-with-proxy/cn1.toml > cn1.log & 
./mo-service -cfg etc/launch-with-proxy/cn2.toml > cn2.log & 
./mo-service -cfg etc/launch-with-proxy/proxy.toml > proxy.log &

[tom-csf]

多cn的事务的问题已经解决， 单个cn oom的问题另外在#20213 跟踪