[MDEV-17016] Assertion `!auto_increment_lock && !auto_increment_safe_stmt_log_lock' failed in ha_partition::external_lock Created: 2018-08-18  Updated: 2019-03-01  Resolved: 2019-02-20

Status: Closed
Project: MariaDB Server
Component/s: Partitioning
Affects Version/s: 10.1, 10.2
Fix Version/s: 10.1.39, 10.3.14

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Julius Goryavsky
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Problem/Incident
is caused by MDEV-9519 Start Slave on a Galera should error ... Closed

 Description    

--source include/have_partition.inc
 
--source include/have_log_bin.inc
 
 
 
CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY) PARTITION BY KEY (pk) PARTITIONS 2;
 
INSERT INTO t1 VALUES (NULL),(NULL);
 
 
 
--error ER_DUP_ENTRY
 
UPDATE t1 SET pk = 2147483647;
 
REPLACE INTO t1 VALUES (NULL);

10.1 75dfd4acb

 
mysqld: /data/src/10.1/sql/ha_partition.cc:3769: virtual int ha_partition::external_lock(THD*, int): Assertion `!auto_increment_lock && !auto_increment_safe_stmt_log_lock' failed.
 
180818 20:17:27 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fb66cb0dee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000055653c7796fa in ha_partition::external_lock (this=0x7fb6640b0088, thd=0x7fb6658da070, lock_type=2) at /data/src/10.1/sql/ha_partition.cc:3769
 
#9  0x000055653c15cb0e in handler::ha_external_lock (this=0x7fb6640b0088, thd=0x7fb6658da070, lock_type=2) at /data/src/10.1/sql/handler.cc:5889
 
#10 0x000055653c240840 in unlock_external (thd=0x7fb6658da070, table=0x7fb6640439d8, count=1) at /data/src/10.1/sql/lock.cc:689
 
#11 0x000055653c23fdbe in mysql_unlock_tables (thd=0x7fb6658da070, sql_lock=0x7fb6640439a0, free_lock=false) at /data/src/10.1/sql/lock.cc:399
 
#12 0x000055653c23fd2a in mysql_unlock_tables (thd=0x7fb6658da070, sql_lock=0x7fb6640439a0) at /data/src/10.1/sql/lock.cc:388
 
#13 0x000055653bea4e5a in close_thread_tables (thd=0x7fb6658da070) at /data/src/10.1/sql/sql_base.cc:1028
 
#14 0x000055653bf19d8e in mysql_execute_command (thd=0x7fb6658da070) at /data/src/10.1/sql/sql_parse.cc:5777
 
#15 0x000055653bf1e2e8 in mysql_parse (thd=0x7fb6658da070, rawbuf=0x7fb664043088 "REPLACE INTO t1 VALUES (NULL)", length=29, parser_state=0x7fb66eb475e0) at /data/src/10.1/sql/sql_parse.cc:7463
 
#16 0x000055653bf0cc7d in dispatch_command (command=COM_QUERY, thd=0x7fb6658da070, packet=0x7fb667554071 "REPLACE INTO t1 VALUES (NULL)", packet_length=29) at /data/src/10.1/sql/sql_parse.cc:1495
 
#17 0x000055653bf0ba02 in do_command (thd=0x7fb6658da070) at /data/src/10.1/sql/sql_parse.cc:1124
 
#18 0x000055653c045e1b in do_handle_one_connection (thd_arg=0x7fb6658da070) at /data/src/10.1/sql/sql_connect.cc:1330
 
#19 0x000055653c045b7f in handle_one_connection (arg=0x7fb6658da070) at /data/src/10.1/sql/sql_connect.cc:1242
 
#20 0x000055653c403b0a in pfs_spawn_thread (arg=0x7fb66c03a3f0) at /data/src/10.1/storage/perfschema/pfs.cc:1861
 
#21 0x00007fb66e811494 in start_thread (arg=0x7fb66eb48b00) at pthread_create.c:333
 
#22 0x00007fb66cbca93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

The problem was introduced by the latest commit:

commit 75dfd4acb995789ca5f86ccbd361fff9d2797e79
 
Author: Julius Goryavsky
 
Date:   Thu Jul 26 15:04:11 2018 +0200
 
 
 
    This is patch for the https://jira.mariadb.org/browse/MDEV-9519 issue:
 
...



 Comments   
Comment by Julius Goryavsky [ 2018-08-19 ]

Fixed regression, which led to assertion activation when compiling in DEBUG mode (only in it) when using partitons and keys outside the allowed range. A new test has been added, which tests this rare situation: https://github.com/MariaDB/server/pull/845

Comment by Jan Lindström (Inactive) [ 2018-08-20 ]

InnoDB code changes ok to push, I will assign rest to serg

Comment by Julius Goryavsky [ 2018-08-31 ]

I added comments to the source - patch fixes the problems by setting the correct value of the insert_id_for_cur_row field (by preventing earlier return from the update_auto_increment() method). In several failed partitions-related tests the write_record() function (which located in the sql_insert.cc file) goes to the "before_trg_err" label (which located near the end of the function). In this case (and without this patch) the table->file->insert_id_for_cur_row field will be zero and, as a result, the restore_auto_increment() function call does not restore the value of next_isert_id field, which in the future results in an error in the release_auto_increment() method.

Comment by Sergei Golubchik [ 2018-08-31 ]

My comment is still valid. The server behaves correctly according to the protocol.

The handler ha_partition makes incorrect assumptions and violates its own assertion. Thus the bug is inside ha_partition and it must be fixed there. Unless you show that the protocol is incomplete, ha_partition does not have enough information and cannot possibly fix the bug properly.

Comment by Julius Goryavsky [ 2018-09-11 ]

I re-published a completely redesigned patch for MDEV-17016 and updated the pull request. Now this patch does not use a hack with a deferred return, instead it relies on the changes to release_auto_increment() method (for partitions) and changes in the sql_insert.cc (to verify that the generated auto-increment value is really consumed by UPDATE). In addition, I made two mtr tests more stable (galera.partitions and galera_binlog_stmt_autoinc, which could give false failures when the second node starts before the first one).

Comment by Julius Goryavsky [ 2019-02-20 ]

All fixes from here are transferred to the updated version of MDEV-9519 (https://github.com/MariaDB/server/pull/1187), so this task can be closed - it was needed only as a supplement to the first version of MDEV-9519.

Generated at Thu Feb 08 08:33:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.