Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.11.11, 11.4.4
-
None
Description
This started off in MXS-5527 where I noticed that INSERT ... RETURNING does not return the value of last_gtid the same way it is for a plain INSERT statement.
Here's a network dump where the behavior is seen. The GTID 0-3000-11 is returned but the GTID
T 127.0.0.1:39908 -> 127.0.0.1:3000 [AP] #24
|
23 00 00 00 03 63 72 65 61 74 65 20 6f 72 20 72 #....create or r
|
65 70 6c 61 63 65 20 74 61 62 6c 65 20 74 31 28 eplace table t1(
|
69 64 20 69 6e 74 29 id int)
|
#
|
T 127.0.0.1:3000 -> 127.0.0.1:39908 [AP] #25
|
1f 00 00 01 00 00 00 02 40 00 00 00 16 00 14 09 ........@.......
|
6c 61 73 74 5f 67 74 69 64 09 30 2d 33 30 30 30 last_gtid.0-3000
|
2d 31 33 -13
|
##
|
T 127.0.0.1:39908 -> 127.0.0.1:3000 [AP] #27
|
27 00 00 00 03 69 6e 73 65 72 74 20 69 6e 74 6f '....insert into
|
20 74 31 20 76 61 6c 75 65 73 20 28 31 29 20 72 t1 values (1) r
|
65 74 75 72 6e 69 6e 67 20 69 64 eturning id
|
#
|
T 127.0.0.1:3000 -> 127.0.0.1:39908 [AP] #28
|
02 00 00 01 01 01 23 00 00 02 03 64 65 66 04 74 ......#....def.t
|
65 73 74 02 74 31 02 74 31 02 69 64 02 69 64 00 est.t1.t1.id.id.
|
0c 3f 00 0b 00 00 00 03 00 00 00 00 00 05 00 00 .?..............
|
03 fe 00 00 02 00 02 00 00 04 01 31 05 00 00 05 ...........1....
|
fe 00 00 02 40 ....@
|
##
|
T 127.0.0.1:39908 -> 127.0.0.1:3000 [AP] #30
|
13 00 00 00 03 73 65 6c 65 63 74 20 40 40 6c 61 .....select @@la
|
73 74 5f 67 74 69 64 st_gtid
|
#
|
T 127.0.0.1:3000 -> 127.0.0.1:39908 [AP] #31
|
02 00 00 01 01 01 22 00 00 02 03 64 65 66 00 00 ......"....def..
|
00 0b 40 40 6c 61 73 74 5f 67 74 69 64 00 00 0c ..@@last_gtid...
|
21 00 1b 00 00 00 fd 00 00 27 00 00 05 00 00 03 !........'......
|
fe 00 00 02 00 0a 00 00 04 09 30 2d 33 30 30 30 ..........0-3000
|
2d 31 34 05 00 00 05 fe 00 00 02 00 -14.........
|
##
|
T 127.0.0.1:39908 -> 127.0.0.1:3000 [AP] #33
|
1a 00 00 00 03 69 6e 73 65 72 74 20 69 6e 74 6f .....insert into
|
20 74 31 20 76 61 6c 75 65 73 20 28 32 29 t1 values (2)
|
#
|
T 127.0.0.1:3000 -> 127.0.0.1:39908 [AP] #34
|
1f 00 00 01 00 01 00 02 40 00 00 00 16 00 14 09 ........@.......
|
6c 61 73 74 5f 67 74 69 64 09 30 2d 33 30 30 30 last_gtid.0-3000
|
2d 31 35 -15
|
##
|
T 127.0.0.1:39908 -> 127.0.0.1:3000 [AP] #36
|
13 00 00 00 03 73 65 6c 65 63 74 20 40 40 6c 61 .....select @@la
|
73 74 5f 67 74 69 64 st_gtid
|
#
|
T 127.0.0.1:3000 -> 127.0.0.1:39908 [AP] #37
|
02 00 00 01 01 01 22 00 00 02 03 64 65 66 00 00 ......"....def..
|
00 0b 40 40 6c 61 73 74 5f 67 74 69 64 00 00 0c ..@@last_gtid...
|
21 00 1b 00 00 00 fd 00 00 27 00 00 05 00 00 03 !........'......
|
fe 00 00 02 00 0a 00 00 04 09 30 2d 33 30 30 30 ..........0-3000
|
2d 31 35 05 00 00 05 fe 00 00 02 00 -15.........
|
Attachments
Issue Links
- blocks
-
-
- Closed
-
I think that this is just an user error, I remembered that the session trackers only show up if the DEPRECATE_EOF capability was set but it's actually present in the OK packets even without it. I tested this again with the Node.js connector which does enable the DEPRECATE_EOF protocol and I do see the GTID visible there. I apologize for the trouble.