执行特定sql，服务宕机

OceanBase 技术问题
#1

在4.3.5bp4和4.3.5bp5均可复现，4.4.1.0没有问题。
具体环境为
uname -a
Linux -Precision-3640-Tower 6.11.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 13 20:29:41 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

observer (OceanBase_CE 4.3.5.5)

REVISION: 105000012025111711-c10174c0486c38f64a2222486986bbe15d5da0dc
BUILD_BRANCH: HEAD
BUILD_TIME: Nov 17 2025 12:20:08
BUILD_FLAGS: RelWithDebInfo
BUILD_INFO:

Copyright (c) 2011-present OceanBase Inc.

执行下面的测试用例服务宕机

CREATE TABLE IF NOT EXISTS t1984 (
    c1 DECIMAL(9, 3) SIGNED ZEROFILL NULL,
    c2 NUMERIC(7, 5) ZEROFILL,
    UNIQUE (c2, c1) USING BTREE LOCAL BLOCK_SIZE 48213
) CHARACTER SET GB18030 COLLATE GB18030_BIN auto_increment_cache_size = 667
WITH
    COLUMN GROUP (ALL COLUMNS);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (297718, 27.59);
INSERT INTO t1984 (c1, c2) VALUES (8550.90, 99);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (6730.810, 7);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (15, 2.6733);
INSERT INTO t1984 (c1, c2) VALUES (835.81, 9.15);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (44.389, 3.769);
INSERT INTO t1984 (c1, c2) VALUES (70.3, 14);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (682, 26);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (957.0, 5);
INSERT INTO t1984 (c1, c2) VALUES (41.9, 28.0);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (9142.353, 18.86);
INSERT INTO t1984 (c1, c2) VALUES (5591, 14.37025);
INSERT INTO t1984 (c1, c2) VALUES (826020.0, 2.0);
INSERT INTO t1984 (c1, c2) VALUES (9.866, 9.23631);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (5.61, 80);
INSERT INTO t1984 (c1, c2) VALUES (75916, 73.893);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (697267, 5.94);
INSERT INTO t1984 (c1, c2) VALUES (5176, 61.63);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (68464.2, 32);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (141, 8);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (50.65, 5.41);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (41205.49, 30.7);
INSERT INTO t1984 (c1, c2) VALUES (42375.31, 9.525);
INSERT INTO t1984 (c1, c2) VALUES (6.003, 4.5242);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (583.34, 44.90);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (9.47, 70.88817);
INSERT INTO t1984 (c1, c2) VALUES (2039.98, 83.61399);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (933096.9, 1.536);
INSERT IGNORE INTO t1984 (c1, c2) VALUES (4.2, 9.114);
INSERT INTO t1984 (c1, c2) VALUES (1499.195, 49.75);


SELECT t1984.c2 AS ca1 FROM t1984 WHERE ((MONTHNAME((TIMESTAMP((TIMESTAMP((FROM_DAYS(-3.1271291853433305E38)), (SEC_TO_TIME(t1984.c1)))))))) IS NULL) ;
#4

感谢反馈 集群crash会生成core文件，麻烦帮忙使用gdb获取一下堆栈
cd /path/observer/bin

gdb observer /path/core_file

进入到 gdb 交互提示符后

set logging file /path/gdb.txt
set logging on
set pagination off
set print pretty on
set print elements 0
bt
bt full
info r
info thread
set logging off
quit
提供一下gdb.txt

#5

我没有找到这个文件，他应该在哪个文件夹

#6

sysctl.conf文件里面设置路径。
这边测试一下该sql，441也存在问题

#7

这边测试441版本堆栈正在获取中。你那边不需要再操作该步骤了

#8

我刚好搞完了一个，我还是发一下吧，4.3.5.5的
gdb.txt (80.1 KB)

1 个赞
#9

该问题已经分析出原因：向量化2.0 month_name表达式优化引入的问题，计算到的月份大于12时访问越界。非向量化路径会转到ob_time，过程中如果发现不合法月份，会根据sql mode报错或者设置null。
回避办法（如待复现请给出下次发生的行动计划）：
使用hint控制 /*+ OPT_PARAM(‘enable_rich_vector_format’, ‘FALSE’) */ 不走向量化2.0可以绕过
4.3.5引入，低于4.3.5无此问题。