Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5, 10.6, 10.9, 10.10, 10.11, 11.0, 11.1, 11.2, 11.3
-
None
Description
--source include/have_innodb.inc
|
--source include/have_binlog_format_row.inc
|
--source include/have_sequence.inc
|
|
|
SET @cachesize= @@max_binlog_cache_size; |
SET GLOBAL MAX_BINLOG_CACHE_SIZE= 65536; |
|
|
CREATE TABLE t1 (pk INT PRIMARY KEY, a VARCHAR(8)) ENGINE=InnoDB; |
|
|
--connect (con1,localhost,root,,test)
|
|
|
XA BEGIN 'xid'; |
INSERT INTO t1 SELECT seq, 'foobar12' FROM seq_1_to_6985; |
XA END 'xid'; |
XA PREPARE 'xid'; |
|
|
# Cleanup
|
XA ROLLBACK 'xid'; |
--disconnect con1
|
--connection default
|
DROP TABLE t1; |
SET GLOBAL MAX_BINLOG_CACHE_SIZE= @cachesize; |
|
10.5 eacefbca debug |
mariadbd: /data/src/10.5/sql/log.cc:10184: virtual int MYSQL_BIN_LOG::unlog_xa_prepare(THD*, bool): Assertion `is_preparing_xa(thd)' failed.
|
210208 20:14:06 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007f3145f28f36 in __GI___assert_fail (assertion=0x555c0e778339 "is_preparing_xa(thd)", file=0x555c0e772f7c "/data/src/10.5/sql/log.cc", line=10184, function=0x555c0e778350 "virtual int MYSQL_BIN_LOG::unlog_xa_prepare(THD*, bool)") at assert.c:101
|
#8 0x0000555c0dc58a4b in MYSQL_BIN_LOG::unlog_xa_prepare (this=0x555c0f1618c0 <mysql_bin_log>, thd=0x7f3108000db8, all=true) at /data/src/10.5/sql/log.cc:10184
|
#9 0x0000555c0db06987 in ha_prepare (thd=0x7f3108000db8) at /data/src/10.5/sql/handler.cc:1421
|
#10 0x0000555c0da38634 in trans_xa_prepare (thd=0x7f3108000db8) at /data/src/10.5/sql/xa.cc:532
|
#11 0x0000555c0d7a2637 in mysql_execute_command (thd=0x7f3108000db8) at /data/src/10.5/sql/sql_parse.cc:5877
|
#12 0x0000555c0d7a92f2 in mysql_parse (thd=0x7f3108000db8, rawbuf=0x7f3108012c00 "XA PREPARE 'xid'", length=16, parser_state=0x7f314023b510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8062
|
#13 0x0000555c0d795275 in dispatch_command (command=COM_QUERY, thd=0x7f3108000db8, packet=0x7f31080091d9 "XA PREPARE 'xid'", packet_length=16, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1889
|
#14 0x0000555c0d793a69 in do_command (thd=0x7f3108000db8) at /data/src/10.5/sql/sql_parse.cc:1370
|
#15 0x0000555c0d9418eb in do_handle_one_connection (connect=0x555c11446968, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
|
#16 0x0000555c0d94164e in handle_one_connection (arg=0x555c11446968) at /data/src/10.5/sql/sql_connect.cc:1312
|
#17 0x0000555c0dea162b in pfs_spawn_thread (arg=0x555c1153fa18) at /data/src/10.5/storage/perfschema/pfs.cc:2201
|
#18 0x00007f3146440609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#19 0x00007f3146014293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
|
10.5 eacefbca non-debug |
mysqltest: At line 15: query 'XA PREPARE 'xid'' failed: 1180: Got error 1 "Operation not permitted" during COMMIT
|
Reproducible on 10.5, 10.6. Not reproducible on 10.4.
The scenario is scalable, it is not limited to the low value of max_binlog_cache_size; but the size of the binlog events needs to be adjusted very precisely, to my understanding the important part is that the failure happens exactly on PREPARE.
The failure started happening on 10.5 after this commit:
commit c8ae357341964382bc099392c6bedc370fa734f5
|
Author: Andrei Elkin
|
Date: Sun Mar 31 01:47:28 2019 +0400
|
|
|
MDEV-742 XA PREPAREd transaction survive disconnect/server restart
|
There is an extra oddity if a non-transactional table is added to the scenario.
|
Error 27 |
--source include/have_innodb.inc
|
--source include/have_binlog_format_row.inc
|
--source include/have_sequence.inc
|
|
|
SET @cachesize= @@max_binlog_cache_size; |
SET GLOBAL MAX_BINLOG_CACHE_SIZE= 65536; |
|
|
CREATE TABLE t1 (pk INT PRIMARY KEY, a VARCHAR(8)) ENGINE=InnoDB; |
CREATE TABLE t2 (pk INT PRIMARY KEY, b VARCHAR(8)) ENGINE=MyISAM; |
|
|
--connect (con1,localhost,root,,test)
|
|
|
SET rand_seed1=661841330, rand_seed2=41699722; |
|
|
XA BEGIN 'xid'; |
INSERT INTO t1 SELECT seq, 'foobar12' FROM seq_1_to_6985; |
INSERT INTO t2 SELECT seq, 'foobar56' FROM seq_1_to_2; |
XA END 'xid'; |
XA PREPARE 'xid'; |
|
|
# Cleanup
|
XA ROLLBACK 'xid'; |
--disconnect con1
|
--connection default
|
DROP TABLE t1, t2; |
SET GLOBAL MAX_BINLOG_CACHE_SIZE= @cachesize; |
This test case fails the same way as the first one – an assertion failure on debug and ER_ERROR_DURING_COMMIT on non-debug; but before that, it produces an extra error in the error log:
2021-02-08 20:18:27 6 [ERROR] mariadbd: Error writing file 'master-bin' (errno: 27 "File too large")
|
As far as I can understand, at least in this scenario, it fails to convert the generic write error into ER_TRANS_CACHE_FULL which is supposed to be produced in this case. The result is very misleading, because system error 27 on relatively modern file systems should be extremely hard to achieve (at least through the binary log).
I am not sure if it will be fixed by a patch for this bug report; if not, please extract it into a separate bug report or let me know that I should do so.