查询导致core dump,与全局字典相关

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】查询引起,单次查询不会出现,多次查询会导致core dump。(是由于前几次查询不会走字典优化,后面的查询都会直接走字典优化。)
【业务影响】
【是否存算分离】否
【StarRocks版本】2.5.4
【附件】
core dump:
terminate called recursively
@ 0x7f5de3f6a630 (unknown)
@ 0x7f5de34b53d7 __GI_raise
@ 0x7f5de34b6ac8 __GI_abort
@ 0x2bb5bb0 _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold
@ 0x813a876 __cxxabiv1::__terminate()
@ 0x813a8e1 std::terminate()
@ 0x813aa34 __cxa_throw
@ 0x28ae16f std::__throw_bad_variant_access()
@ 0x28ae18c std::__throw_bad_variant_access()
@ 0x431f291 starrocks::vectorized::ColumnPredicateRewriter::_rewrite_predicate()
@ 0x4321125 starrocks::vectorized::ColumnPredicateRewriter::rewrite_predicate()
@ 0x4223103 starrocks::vectorized::SegmentIterator::_rewrite_predicates()
@ 0x422f21d starrocks::vectorized::SegmentIterator::_init()
@ 0x422f680 starrocks::vectorized::SegmentIterator::do_get_next()
@ 0x42a3872 starrocks::vectorized::ProjectionIterator::do_get_next()
@ 0x485e1e5 starrocks::SegmentIteratorWrapper::do_get_next()
@ 0x467b043 starrocks::vectorized::TimedChunkIterator::do_get_next()
@ 0x42de82c starrocks::vectorized::UnionIterator::do_get_next()
@ 0x42cc03e starrocks::vectorized::TabletReader::do_get_next()
@ 0x30acf7b starrocks::pipeline::OlapChunkSource::_read_chunk_from_storage()
@ 0x30ad669 starrocks::pipeline::OlapChunkSource::_read_chunk()
@ 0x309d1cc starrocks::pipeline::ChunkSource::buffer_next_batch_chunks_blocking()
@ 0x2e185a4 _ZZN9starrocks8pipeline12ScanOperator18_trigger_next_scanEPNS_12RuntimeStateEiENKUlvE_clEv
@ 0x2e2972e starrocks::workgroup::ScanExecutor::worker_thread()
@ 0x4a6e4c2 starrocks::ThreadPool::dispatch_thread()
@ 0x4a68f5a starrocks::thread::supervise_thread()
@ 0x7f5de3f62ea5 start_thread
@ 0x7f5de357d9fd __clone

gdb发现可能与全局字典相关:


触发条件是filter:gaia_name=‘nj-musca-gaia’

你好 版本是2.5.4吗 可以升级下版本哈 当前最细拿到2.5版本是2.5.21 修复过类似的问题

明白,版本确实是2.5.4,不过最近这个用户的集群不太方便直接升级,大佬知道是具体哪个修复吗?我好cherry-pick过来。补充:昨天发现是因为schema里有两个重复的对象,所以rewrite了两次,造成了rewrite_predicate的问题。

set cbo_enable_low_cardinality_optimize=false; 试试?

感谢大佬,我们已经通过/api/global_dict/table/enable?db_name=xxx 把对应表的全局字典禁用了。目前环境使用没什么问题,我们再找找本质原因