[MCOL-5599] LIKE '%1%' in WHERE part never finishes Created: 2023-10-26  Updated: 2024-02-05  Resolved: 2023-12-19

Status: Closed
Project: MariaDB ColumnStore
Component/s: PrimProc
Affects Version/s: 23.10.0
Fix Version/s: 23.10.1

Type: Bug Priority: Major
Reporter: Roman Assignee: Sergey Zefirov
Resolution: Fixed Votes: 1
Labels: None

Sprint: 2023-11

 Description   

Consider the case

MariaDB [test]> create table foo (a varchar(10)) engine=columnstore;
Query OK, 0 rows affected (9.094 sec)
 
MariaDB [test]>
MariaDB [test]> insert into foo values ('dkdj');
Query OK, 1 row affected (1.855 sec)
 
MariaDB [test]> select * from foo where a like '%k%';
+------+
| a    |
+------+
| dkdj |
+------+
1 row in set (0.022 sec)
 
MariaDB [test]> select * from foo where a like '%1%'; <================ This query is running forever



 Comments   
Comment by Roman [ 2023-10-26 ]

Here is the call stack of the thread that stuck.

TID 603620:
#0  0x00007ff69d3a8091 __memmove_avx_unaligned_erms_rtm
#1  0x000055f3d9472aa6 std::char_traits<char>::move(char*, char const*, unsigned long)
#2  0x000055f3d947b97e std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_move(char*, char const*, unsigned long)
#3  0x000055f3d947b78d std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)
#4  0x000055f3d947ade7 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::replace(unsigned long, unsigned long, char const*, unsigned long)
#5  0x00007ff69fbd88be std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::replace(unsigned long, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<ch
ar> > const&)
#6  0x00007ff69dde5eaa void logging::formatOne<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, __gnu_cxx::__normal_iterator<boost::any const*, std::vector<boost::any, std::allocator<b
oost::any> > > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, __gnu_cxx::__normal_iterator<boost::any const*, std::vector<boost::any, std::allocator<boost::any> > >, unsigned int)
#7  0x00007ff69dde33f8 void logging::formatMany<std::vector<boost::any, std::allocator<boost::any> > >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::vector<boost::any, std::al
locator<boost::any> > const&)
#8  0x00007ff69dddc906 logging::Message::format(logging::Message::Args const&)
#9  0x00007ff69de1990f logging::Logger::logMessage[abi:cxx11](logging::LOG_TYPE, unsigned int, logging::Message::Args const&, logging::LoggingID const&)
#10 0x00007ff69de1cc99 logging::SQLLogger::logMessage(logging::LOG_TYPE, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)
#11 0x00007ff69de1c95b logging::SQLLogger::SQLLogger(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, logging::LoggingID const&)
#12 0x000055f3d9537a4f exemgr::SQLFrontSessionThread::operator()()
#13 0x000055f3d95330dd boost::detail::function::void_function_obj_invoker0<exemgr::SQLFrontSessionThread, void>::invoke(boost::detail::function::function_buffer&)
#14 0x00007ff69dad3d15 boost::function0<void>::operator()() const
#15 0x00007ff69dad16e5 threadpool::ThreadPool::beginThread()
#16 0x00007ff69dad33c5 threadpool::ThreadPool::beginThreadFunc::operator()()
#17 0x00007ff69dad7260 boost::detail::thread_data<threadpool::ThreadPool::beginThreadFunc>::run()
#18 0x000055f3d954d0db thread_proxy
#19 0x00007ff69d294ac3 start_thread
#20 0x00007ff69d326a40 __clone3

Comment by Kirill Perov [ 2023-12-19 ]

fixed

Comment by suresh ramagiri [ 2024-01-18 ]

Hi drrtuy, sergey.zefirov,
Customer was asking in the support ticket, whether the fix provided here, will cover the pattern in the WHERE clause column as '%abc%1%'?
Could you please confirm it. Thanks!

Comment by Sergey Zefirov [ 2024-01-18 ]

suresh.ramagiri@mariadb.com

Yes, the fix for the problem in this ticket covers that pattern too.

Generated at Thu Feb 08 02:59:04 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.