Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
Note: In the test case below, the contents of the table after UPDATE FOR PORTION is already wrong, see MDEV-22414 for it. I am not sure whether the following assertion is related to it, though.
CREATE TABLE t1 (id INT AUTO_INCREMENT, s TIMESTAMP, e TIMESTAMP, PERIOD FOR p(s,e), PRIMARY KEY(id)) WITH SYSTEM VERSIONING; |
INSERT INTO t1 VALUES (1,'2001-09-12','2029-05-26'); |
UPDATE t1 FOR PORTION OF p FROM '2004-12-20' TO '2022-07-09' SET id = 0; |
UPDATE t1 SET id = 4; |
|
|
# Cleanup
|
DROP TABLE t1; |
|
10.4 38f6c47f |
mysqld: /data/src/10.4/sql/handler.cc:6408: int handler::ha_external_lock(THD*, int): Assertion `next_insert_id == 0' failed.
|
200514 20:18:52 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007f69cabfbf12 in __GI___assert_fail (assertion=0x55b18f08b287 "next_insert_id == 0", file=0x55b18f0892a9 "/data/src/10.4/sql/handler.cc", line=6408, function=0x55b18f08da40 <handler::ha_external_lock(THD*, int)::__PRETTY_FUNCTION__> "int handler::ha_external_lock(THD*, int)") at assert.c:101
|
#8 0x000055b18e54f1ed in handler::ha_external_lock (this=0x7f69b41335d8, thd=0x7f69b4000af0, lock_type=2) at /data/src/10.4/sql/handler.cc:6408
|
#9 0x000055b18e682c00 in unlock_external (thd=0x7f69b4000af0, table=0x7f69b4013cc0, count=1) at /data/src/10.4/sql/lock.cc:710
|
#10 0x000055b18e681fff in mysql_unlock_tables (thd=0x7f69b4000af0, sql_lock=0x7f69b4013c90, free_lock=false) at /data/src/10.4/sql/lock.cc:431
|
#11 0x000055b18e681f56 in mysql_unlock_tables (thd=0x7f69b4000af0, sql_lock=0x7f69b4013c90) at /data/src/10.4/sql/lock.cc:417
|
#12 0x000055b18e142d52 in close_thread_tables (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_base.cc:1012
|
#13 0x000055b18e1f1cd8 in mysql_execute_command (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_parse.cc:6167
|
#14 0x000055b18e1f6b4d in mysql_parse (thd=0x7f69b4000af0, rawbuf=0x7f69b4013198 "UPDATE t1 SET id = 4", length=20, parser_state=0x7f69c4da5570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7900
|
#15 0x000055b18e1e30fd in dispatch_command (command=COM_QUERY, thd=0x7f69b4000af0, packet=0x7f69b4136221 "UPDATE t1 SET id = 4", packet_length=20, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
|
#16 0x000055b18e1e189f in do_command (thd=0x7f69b4000af0) at /data/src/10.4/sql/sql_parse.cc:1360
|
#17 0x000055b18e369458 in do_handle_one_connection (connect=0x55b191b53cf0) at /data/src/10.4/sql/sql_connect.cc:1412
|
#18 0x000055b18e3691a7 in handle_one_connection (arg=0x55b191b53cf0) at /data/src/10.4/sql/sql_connect.cc:1316
|
#19 0x000055b18ed6946b in pfs_spawn_thread (arg=0x55b191b6fbf0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#20 0x00007f69ccb844a4 in start_thread (arg=0x7f69c4da6700) at pthread_create.c:456
|
#21 0x00007f69cacb8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
Reproducible on 10.4-10.5 with at least MyISAM and InnoDB.
The test case is not applicable to 10.3.
Non-debug build doesn't crash or produce anything obviously unexpected upon the last UPDATE, but wrong contents caused by MDEV-22414 is present there as well.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-