[MDEV-21650] Non-empty statement transaction on global rollback after TRT update error Created: 2020-02-04  Updated: 2022-01-13  Resolved: 2022-01-13

Status: Closed
Project: MariaDB Server
Component/s: Server, Versioned Tables
Affects Version/s: 10.4, 10.5, 10.6, 10.7
Fix Version/s: 10.4.23, 10.5.14, 10.6.6, 10.7.2, 10.8.1

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: trx-versioning

Issue Links:
Blocks
Relates
relates to MDEV-18875 Assertion `thd->transaction.stmt.ha_l... Closed
relates to MDEV-27040 Was: Assertion `thd->transaction->stm... Open

 Description   

Note: There seems to be many things in this test which should be redundant (like, for example, attempt to create an already existing application period in ALTER, and more), but I can't get rid of any of them.

Assertion `thd->transaction.stmt.ha_list == __null || trans == &thd->transaction.stmt' failed in ha_rollback_trans with versioned tables

--source include/have_innodb.inc
 
CREATE TABLE t1 (s DATE, e DATE, PERIOD FOR app(s,e)) ENGINE=InnoDB;
ALTER TABLE t1
    ADD row_start BIGINT UNSIGNED AS ROW START,
    ADD row_end BIGINT UNSIGNED AS ROW END,
    ADD PERIOD FOR SYSTEM_TIME(row_start,row_end),
    WITH SYSTEM VERSIONING,
    ADD PERIOD IF NOT EXISTS FOR app(x,y);
 
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;
INSERT INTO t1 (s,e) VALUES ('2021-07-04','2024-08-18');
 
--connect (con1,localhost,root,,test)
START TRANSACTION;
INSERT INTO t1 (s,e) VALUES ('2018-06-01','2021-09-15');
 
--connection default
--error ER_VERS_NO_TRX_ID
SELECT * FROM t1 FOR SYSTEM_TIME AS OF NOW();
 
--connection con1
SET innodb_lock_wait_timeout= 1, lock_wait_timeout= 1;
# Can be existing or non-existing table, does not matter
--error ER_LOCK_WAIT_TIMEOUT
ALTER TABLE xx;
 
# Cleanup
--disconnect con1
--connection default
DROP TABLE t1;

10.4 b615d275

mysqld: /data/src/10.4/sql/handler.cc:1836: int ha_rollback_trans(THD*, bool): Assertion `thd->transaction.stmt.ha_list == __null || trans == &thd->transaction.stmt' failed.
200204  1:57:22 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fe5237bcf12 in __GI___assert_fail (assertion=0x55903473a140 "thd->transaction.stmt.ha_list == __null || trans == &thd->transaction.stmt", file=0x559034739ad1 "/data/src/10.4/sql/handler.cc", line=1836, function=0x55903473c9a0 <ha_rollback_trans(THD*, bool)::__PRETTY_FUNCTION__> "int ha_rollback_trans(THD*, bool)") at assert.c:101
#8  0x0000559033bf6f2b in ha_rollback_trans (thd=0x7fe4c4000af0, all=true) at /data/src/10.4/sql/handler.cc:1835
#9  0x0000559033bf689b in ha_commit_trans (thd=0x7fe4c4000af0, all=true) at /data/src/10.4/sql/handler.cc:1690
#10 0x0000559033a2f201 in trans_commit_implicit (thd=0x7fe4c4000af0) at /data/src/10.4/sql/transaction.cc:301
#11 0x0000559033894690 in mysql_execute_command (thd=0x7fe4c4000af0) at /data/src/10.4/sql/sql_parse.cc:3709
#12 0x00005590338a38e3 in mysql_parse (thd=0x7fe4c4000af0, rawbuf=0x7fe4c4011dd8 "ALTER TABLE xx", length=14, parser_state=0x7fe51cb1a160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
#13 0x000055903388eab0 in dispatch_command (command=COM_QUERY, thd=0x7fe4c4000af0, packet=0x7fe4c40083a1 "ALTER TABLE xx", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
#14 0x000055903388d13d in do_command (thd=0x7fe4c4000af0) at /data/src/10.4/sql/sql_parse.cc:1360
#15 0x0000559033a16357 in do_handle_one_connection (connect=0x55903733c050) at /data/src/10.4/sql/sql_connect.cc:1412
#16 0x0000559033a160a6 in handle_one_connection (arg=0x55903733c050) at /data/src/10.4/sql/sql_connect.cc:1316
#17 0x000055903441e9c9 in pfs_spawn_thread (arg=0x559037260020) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#18 0x00007fe5257454a4 in start_thread (arg=0x7fe51cb1b700) at pthread_create.c:456
#19 0x00007fe523879d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.4, 10.5.
The test case is not applicable to 10.3 because of the application period (see comments in regard to 10.3).
No obvious problem on a non-debug build, but there can be hidden ones.



 Comments   
Comment by Elena Stepanova [ 2020-06-17 ]

In 10.5 the assertion was changed to this:

thd->transaction->stmt.ha_list == __null || trans == &thd->transaction->stmt

(transaction->stmt instead of transaction.stmt)

Comment by Elena Stepanova [ 2020-06-17 ]

Here is a test case which doesn't require application periods, and was also failing on 10.3 (non-deterministically, run with --repeat and try running on disk if it doesn't fail in shm):

--source include/have_innodb.inc
 
SET @stats.save= @@innodb_stats_persistent;
SET GLOBAL innodb_stats_persistent= ON;
 
CREATE TABLE t1 (id INT) ENGINE=InnoDB;
ALTER TABLE t1
    ADD row_start BIGINT UNSIGNED AS ROW START,
    ADD row_end BIGINT UNSIGNED AS ROW END,
    ADD PERIOD FOR SYSTEM_TIME(row_start,row_end),
    WITH SYSTEM VERSIONING;
INSERT INTO t1 (id) VALUES (1),(2),(3);
 
--connect (con1,localhost,root,,test)
SET system_versioning_asof = CURRENT_TIMESTAMP;
--send
UPDATE t1 t1a JOIN t1 t1b SET t1a.id = 1;
--connection default
SET AUTOCOMMIT= OFF;
INSERT INTO t1 () VALUES ();
--connection default
--error ER_NO_SUCH_TABLE,ER_LOCK_DEADLOCK
ALTER TABLE x;
--connection con1
--error 0,ER_LOCK_DEADLOCK
--reap
 
# Cleanup
--disconnect con1
--connection default
DROP TABLE t1;
SET GLOBAL innodb_stats_persistent= @stats.save;

However, it apparently depends on system_versioning_asof being (erroneously) applied to multi-update, and it stopped failing on 10.3 after the patch for MDEV-22906.

Comment by Aleksey Midenkov [ 2021-08-24 ]

Please review in bb-10.4-midenok

Comment by Nikita Malyavin [ 2021-10-29 ]

looks good for me

Comment by Roel Van de Paar [ 2021-11-13 ]

See MDEV-27040

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