Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20360

Assertion bitmap_is_set(read_partitions) upon updating view of join

    Details

      Description

      Assertion `bitmap_is_set(&(m_part_info->read_partitions), part_id)' failed in ha_partition::part_records.

      Since the scope of MDEV-20336 was narrowed down to SELECT FOR UPDATE, I'm not re-opening it, but filing a new one instead.

      --source include/have_partition.inc
       
      CREATE TABLE t (a INT, b INT) WITH SYSTEM VERSIONING PARTITION BY system_time LIMIT 100 ( PARTITION p1 HISTORY, PARTITION pn CURRENT );
      CREATE ALGORITHM=MERGE VIEW v AS SELECT t1.a FROM t AS t1 JOIN t AS t2 ON t1.a = t2.b;
      UPDATE v SET a = NULL;
       
      # Cleanup
      DROP VIEW v;
      DROP TABLE t;
      

      10.3 c23a5e0e

      mysqld: /data/src/10.3/sql/ha_partition.h:1508: ha_rows ha_partition::part_records(void*): Assertion `bitmap_is_set(&(m_part_info->read_partitions), part_id)' failed.
      190816  0:17:41 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fecf9299f12 in __GI___assert_fail (assertion=0x55e4985f8198 "bitmap_is_set(&(m_part_info->read_partitions), part_id)", file=0x55e4985f8148 "/data/src/10.3/sql/ha_partition.h", line=1508, function=0x55e4985f8f80 <ha_partition::part_records(void*)::__PRETTY_FUNCTION__> "ha_rows ha_partition::part_records(void*)") at assert.c:101
      #8  0x000055e497ba03e7 in ha_partition::part_records (this=0x7fecd80968f8, _part_elem=0x7fecd8098b70) at /data/src/10.3/sql/ha_partition.h:1508
      #9  0x000055e497b9afea in partition_info::vers_set_hist_part (this=0x7fecd80988c8, thd=0x7fecd8000b00) at /data/src/10.3/sql/partition_info.cc:842
      #10 0x000055e4984b93ad in ha_partition::external_lock (this=0x7fecd80968f8, thd=0x7fecd8000b00, lock_type=1) at /data/src/10.3/sql/ha_partition.cc:3960
      #11 0x000055e497d66209 in handler::ha_external_lock (this=0x7fecd80968f8, thd=0x7fecd8000b00, lock_type=1) at /data/src/10.3/sql/handler.cc:6371
      #12 0x000055e497e7e33e in lock_external (thd=0x7fecd8000b00, tables=0x7fecd8017c88, count=2) at /data/src/10.3/sql/lock.cc:391
      #13 0x000055e497e7e020 in mysql_lock_tables (thd=0x7fecd8000b00, sql_lock=0x7fecd8017c28, flags=0) at /data/src/10.3/sql/lock.cc:336
      #14 0x000055e497e7dedc in mysql_lock_tables (thd=0x7fecd8000b00, tables=0x7fecd8017c18, count=2, flags=0) at /data/src/10.3/sql/lock.cc:299
      #15 0x000055e4979d016a in lock_tables (thd=0x7fecd8000b00, tables=0x7fecd80128f0, count=2, flags=0) at /data/src/10.3/sql/sql_base.cc:5305
      #16 0x000055e497b589f6 in mysql_multi_update_prepare (thd=0x7fecd8000b00) at /data/src/10.3/sql/sql_update.cc:1725
      #17 0x000055e497a5b866 in mysql_execute_command (thd=0x7fecd8000b00) at /data/src/10.3/sql/sql_parse.cc:4327
      #18 0x000055e497a66da0 in mysql_parse (thd=0x7fecd8000b00, rawbuf=0x7fecd8012818 "UPDATE v SET a = NULL", length=21, parser_state=0x7fecf443e5e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7829
      #19 0x000055e497a5499a in dispatch_command (command=COM_QUERY, thd=0x7fecd8000b00, packet=0x7fecd8008c71 "UPDATE v SET a = NULL", packet_length=21, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
      #20 0x000055e497a533bd in do_command (thd=0x7fecd8000b00) at /data/src/10.3/sql/sql_parse.cc:1401
      #21 0x000055e497bbd562 in do_handle_one_connection (connect=0x55e499d0e120) at /data/src/10.3/sql/sql_connect.cc:1403
      #22 0x000055e497bbd2c4 in handle_one_connection (arg=0x55e499d0e120) at /data/src/10.3/sql/sql_connect.cc:1308
      #23 0x000055e49849901e in pfs_spawn_thread (arg=0x55e499d290a0) at /data/src/10.3/storage/perfschema/pfs.cc:1862
      #24 0x00007fecfae0e4a4 in start_thread (arg=0x7fecf443f700) at pthread_create.c:456
      #25 0x00007fecf9356d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Just as MDEV-20336, the failure started happening on 10.3 after this commit:

      commit cdbac54df0bd857a053decd66b6067abf15a6801 43882e764d6867c6855b1ff057758a3f08b25c55
      Commit:     Aleksey Midenkov
      CommitDate: Sun Aug 11 12:32:08 2019 +0300
       
          MDEV-17613 MIN/MAX Optimization (Select tables optimized away) does not work
          
          Prune to now-partition when there is no FOR SYSTEM_TIME clause.
      

      No obvious effect on a non-debug build.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                midenok Aleksey Midenkov
                Reporter:
                elenst Elena Stepanova
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: