Hi MariaDB Devs, I tried to evaluate spider engine and found an issue where it crashes, most likely due to MDEV-11084 (Stacktrace and reproducible test case attached).
That also leads me to wonder about the performance for partitioned tables after MDEV-11084, when it seems to close partitions whenever it is not used in a statement (i.e. require it to be reopened in the next statement that would use another partition, effectively not using the open table cache). I cannot see anything mentioned in the final commit message hinting on that it closes partitions not used in the current query, but in the previous patches it was mentioned without any reason. Why does it close the already opened partitions? https://github.com/MariaDB/server/blob/10.3/sql/ha_partition.cc#L8365 I would not mind opening the partitions only when they are to be used (even though there are engines that need to be tested more), but closing them makes no sense to me performance wise. Also notice that the partitions first will be put back into the open table cache and then on the next query the non-used partitions will be closed and the needed ones be (re)-opened. Regards Mattias Jonsson
The stacktrace we got is the same as this: (gdb) bt #0 code_state () at /data0/build/majonsson/server/dbug/dbug.c:354 #1 0x00005555566b941d in _db_enter_ ( _func_=0x7fffec561bbc "ha_spider::position", _file_=0x7fffec560dc0 "/data0/build/majonsson/server/storage/spider/ha_spider.cc", _line_=7862, _stack_frame_=0x7ffff410a090) at /data0/build/majonsson/server/dbug/dbug.c:1105 #2 0x00007fffec4ec9a6 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") at /data0/build/majonsson/server/storage/spider/ha_spider.cc:7862 #3 0x00007fffec4ecac4 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") at /data0/build/majonsson/server/storage/spider/ha_spider.cc:7874 #4 0x00007fffec4ecac4 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") at /data0/build/majonsson/server/storage/spider/ha_spider.cc:7874 #5 0x00007fffec4ecac4 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") at /data0/build/majonsson/server/storage/spider/ha_spider.cc:7874 #6 0x00007fffec4ecac4 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") at /data0/build/majonsson/server/storage/spider/ha_spider.cc:7874 #7 0x00007fffec4ecac4 in ha_spider::position (this=0x7fff9c0cf528, record=0x7fff9c13d6bf "\245\004") ---Type <return> to continue, or q <return> to quit---q at /data0/build/majonsson/server/storage/sQuit (gdb) l 7857 } 7858 7859 void ha_spider::position( 7860 const uchar *record 7861 ) { 7862 DBUG_ENTER("ha_spider::position"); 7863 DBUG_PRINT("info",("spider this=%p", this)); 7864 if (pushed_pos) 7865 { 7866 DBUG_PRINT("info",("spider pushed_pos=%p", pushed_pos)); (gdb) l 7867 memcpy(ref, pushed_pos, ref_length); 7868 DBUG_VOID_RETURN; 7869 } 7870 if (pt_clone_last_searcher) 7871 { 7872 /* sercher is cloned handler */ 7873 DBUG_PRINT("info",("spider cloned handler access")); 7874 pt_clone_last_searcher->position(record); 7875 memcpy(ref, pt_clone_last_searcher->ref, ref_length); 7876 } else { (gdb) p pt_clone_last_searcher $1 = (ha_spider *) 0x7fff9c0cf528 (gdb) p this $2 = (ha_spider * const) 0x7fff9c0cf528 I.e. infinite recursion. It happens in b4a2baffa82e5c07b96a1c752228560dcac1359b but not before. Also found related crash when first using the non-first partition, both cases are in the following test case: echo CREATE TABLE ta_l2 ( a INT, b CHAR(1), c DATETIME, PRIMARY KEY(a) ) MASTER_1_ENGINE MASTER_1_COMMENT2_P_2_1; eval CREATE TABLE ta_l2 ( a INT, b CHAR(1), c DATETIME, PRIMARY KEY(a), KEY(b) ) $MASTER_1_ENGINE $MASTER_1_COMMENT2_P_2_1; INSERT INTO ta_l2 (a, b, c) VALUES (1, 'a', '2008-08-01 10:21:39'), (2, 'b', '2000-01-01 00:00:00'), (3, 'e', '2007-06-04 20:03:11'), (4, 'd', '2003-11-30 05:01:03'), (5, 'c', '2001-12-31 23:59:59'); --enable_query_log --echo --echo Spider crashes if you do not use the first partition first --echo after MDEV-11084 (b4a2baffa82e5c07b96a1c752228560dcac1359b) SELECT a,b,c FROM ta_l2 PARTITION (pt2); --echo --echo Explicit partition selection SELECT a,b,c FROM ta_l2 PARTITION (pt1); --echo This also crashes after b4a2baffa82e5c07b96a1c752228560dcac1359b SELECT min(a), max(a), min(b), max(b) FROM ta_l2; SELECT a,b,c FROM ta_l2 PARTITION (pt2); Full test case diff in separate file.
spider_crash_test.diff
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp