[MDEV-21650] Non-empty statement transaction on global rollback after TRT update error - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.4(EOL), 10.5, 10.6, 10.7(EOL)
Fix Version/s: 10.4.23, 10.5.14, 10.6.6, 10.7.2, 10.8.1
Component/s: Server, Versioned Tables
Labels:
- trx-versioning

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.

Attachments

Issue Links

relates to

MDEV-18875 Assertion `thd->transaction.stmt.ha_list == __null || trans == &thd->transaction.stmt' failed or bogus ER_DUP_ENTRY upon ALTER TABLE with versioning

Closed

MDEV-27040 Was: Assertion `thd->transaction->stmt.ha_list == __null || trans == &thd->transaction->stmt' failed in ha_rollback_trans

Open

Activity

Ascending order - Click to sort in descending order

Elena Stepanova added a comment - 2020-06-17 11:58 - edited

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)

Elena Stepanova added a comment - 2020-06-17 11:58 - edited 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 )

Elena Stepanova added a comment - 2020-06-17 12:20

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~~.

Elena Stepanova added a comment - 2020-06-17 12:20 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 .

Aleksey Midenkov added a comment - 2021-08-24 08:27

Please review in bb-10.4-midenok

Aleksey Midenkov added a comment - 2021-08-24 08:27 Please review in bb-10.4-midenok

Nikita Malyavin added a comment - 2021-10-29 13:35

looks good for me

Nikita Malyavin added a comment - 2021-10-29 13:35 looks good for me

Roel Van de Paar added a comment - 2021-11-13 06:47

See MDEV-27040

Roel Van de Paar added a comment - 2021-11-13 06:47 See MDEV-27040