Bug #102031 reprepare at the beginning of an implicit trans will cause 1837 error
Submitted: 19 Dec 2020 5:23 Modified: 3 Jun 18:39
Reporter: Xiaofeng Dong Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Prepared statements Severity:S3 (Non-critical)
Version:5.6, 5.7, 8.0 OS:Any
Assigned to: CPU Architecture:Any

[19 Dec 2020 5:23] Xiaofeng Dong
Description:
After setting a gtid, execute a prepared statment, it starts an implicit transaction, if the statment needs to reprepare, it will raise an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error.

2020-12-16T15:16:24.218156+08:00          145 Query     SET @@SESSION.GTID_NEXT= '4bfc1188-1867-11e8-8341-fa163e6a13ba:1766177'/*!*/

2020-12-16T15:16:24.218493+08:00          145 Execute   INSERT INTO test_utf8 (`id` , `name` ) values ( 0x3931 , 0x746573743931 )

2020-12-16T15:16:24.219153+08:00          145 Prepare   INSERT INTO test_utf8 (`id` , `name` ) values ( ? , ? )

2020-12-16T15:16:24.219169+08:00          145 Execute   INSERT INTO test_utf8 (`id` , `name` ) values ( 0x3931 , 0x746573743931 )

return: "When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual page for detailed explanation. Current @@SESSION.GTID_NEXT is 'xxx-xx-xx-xx:nnn'.

Before repreparing, executing will be rollbacked in trans_rollback_stmt(), gtid_next.type is set to UNDEFINED_GROUP.

How to repeat:
# reprepare_with_gtid-master.opt

--gtid-mode=ON --enforce-gtid-consistency=ON --log-bin

##############################################################

# reprepare_with_gtid.test

--source include/not_embedded.inc
--source include/have_gtid.inc
--source include/have_innodb.inc

--disable_warnings
drop table if exists t1;
--enable_warnings

create table t1 (a int);
prepare stmt1 from 'insert into t1 values (?)';
set @a = 1;

connect (conn1,localhost,root,,);
connection conn1;
truncate table t1;
disconnect conn1;

connection default;
set gtid_next = '52c197f6-4de9-4997-abfa-b7401d8b59de:15';
begin;
execute stmt1 using @a;
select * from t1;
commit;

connect (conn1,localhost,root,,);
connection conn1;
truncate table t1;
disconnect conn1;

connection default;
set gtid_next = '52c197f6-4de9-4997-abfa-b7401d8b59de:20';
# begin;
# --error ER_GTID_NEXT_TYPE_UNDEFINED_GROUP
execute stmt1 using @a;
select * from t1;
# commit;

set gtid_next = 'AUTOMATIC';
deallocate prepare stmt1;
drop table t1;
[25 Dec 2020 8:45] MySQL Verification Team
Hi,

Thanks for the report and the test case.

All best
Bogdan
[3 Jun 18:39] Paul DuBois
Posted by developer:
 
Fixed in 5.7.35, 8.0.26.

Repreparation of a prepared statement at the beginning of an implicit
transaction could cause an ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error.