← Back to team overview

maria-developers team mailing list archive

Questions regarding closing partitions in MDEV-11084

 

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.

Attachment: spider_crash_test.diff
Description: Binary data