[MDEV-28576] RENAME COLUMN with NOCOPY algorithm leads to corrupt partitioned table Created: 2022-05-16  Updated: 2022-12-01  Resolved: 2022-10-06

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Partitioning
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8
Fix Version/s: 10.3.37, 10.4.27, 10.5.18, 10.6.11, 10.7.7, 10.8.6, 10.9.4, 10.10.2

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-30112 ASAN errors in Item_ident::print / ge... Closed
Relates
relates to MDEV-16290 ALTER TABLE ... RENAME COLUMN syntax Closed

 Description   

--source include/have_partition.inc
 
CREATE TABLE t (a INT, b INT) PARTITION BY LIST (b) (PARTITION p1 VALUES IN (1,2));
INSERT INTO t VALUES (0,1),(2,2);
 
ALTER TABLE t RENAME COLUMN b TO f, RENAME COLUMN a TO b, ALGORITHM=NOCOPY;
CHECK TABLE t;
DELETE FROM t ORDER BY b LIMIT 1;
 
# Cleanup
DROP TABLE t;

In the test case above, ALTER TABLE succeeds, and CHECK TABLE already demonstrates the expectedly problematic outcome:

10.5 3fabdc3c

Table	Op	Msg_type	Msg_text
test.t	check	error	Partition p1 returned error
test.t	check	error	Unknown - internal error 160 during operation

Further DELETE causes a debug assertion failure:

mariadbd: /data/src/10.5/sql/ha_partition.cc:4750: virtual int ha_partition::delete_row(const uchar*): Assertion `!error' failed.
220516 16:12:39 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f40f52f6662 in __GI___assert_fail (assertion=0x558c20d1b771 "!error", file=0x558c20d19e88 "/data/src/10.5/sql/ha_partition.cc", line=4750, function=0x558c20d1b860 "virtual int ha_partition::delete_row(const uchar*)") at assert.c:101
#8  0x0000558c203d9fab in ha_partition::delete_row (this=0x7f40d4041e80, buf=0x7f40d4102738 <incomplete sequence \371>) at /data/src/10.5/sql/ha_partition.cc:4750
#9  0x0000558c200bab6f in handler::ha_delete_row (this=0x7f40d4041e80, buf=0x7f40d4102738 <incomplete sequence \371>) at /data/src/10.5/sql/handler.cc:7328
#10 0x0000558c2028d3c7 in TABLE::delete_row (this=0x7f40d4061638) at /data/src/10.5/sql/sql_delete.cc:280
#11 0x0000558c2028a29a in mysql_delete (thd=0x7f40d4000db8, table_list=0x7f40d40153f8, conds=0x0, order_list=0x7f40d4005a10, limit=1, options=0, result=0x0) at /data/src/10.5/sql/sql_delete.cc:817
#12 0x0000558c1fd4052d in mysql_execute_command (thd=0x7f40d4000db8) at /data/src/10.5/sql/sql_parse.cc:4882
#13 0x0000558c1fd4af0b in mysql_parse (thd=0x7f40d4000db8, rawbuf=0x7f40d4015310 "DELETE FROM t ORDER BY b LIMIT 1", length=32, parser_state=0x7f40f04b4510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8116
#14 0x0000558c1fd37034 in dispatch_command (command=COM_QUERY, thd=0x7f40d4000db8, packet=0x7f40d400b5c9 "DELETE FROM t ORDER BY b LIMIT 1", packet_length=32, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1907
#15 0x0000558c1fd357c0 in do_command (thd=0x7f40d4000db8) at /data/src/10.5/sql/sql_parse.cc:1375
#16 0x0000558c1fee2cd3 in do_handle_one_connection (connect=0x558c23b9b958, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1418
#17 0x0000558c1fee2995 in handle_one_connection (arg=0x558c23b7b468) at /data/src/10.5/sql/sql_connect.cc:1312
#18 0x0000558c203f2e84 in pfs_spawn_thread (arg=0x558c23b9b6d8) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#19 0x00007f40f57c2ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#20 0x00007f40f53bfdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Reproducible with at least MyISAM and InnoDB.

With ALGORITHM=COPY the ALTER fails and thus no corruption occurs:

ALTER TABLE t RENAME COLUMN b TO f, RENAME COLUMN a TO b, ALGORITHM=COPY;
ERROR HY000: Table has no partition for value 0
CHECK TABLE t;
Table	Op	Msg_type	Msg_text
test.t	check	status	OK
SHOW CREATE TABLE t;
Table	Create Table
t	CREATE TABLE `t` (
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1



 Comments   
Comment by Aleksey Midenkov [ 2022-09-28 ]

Please review bb-10.5-midenok

Comment by Alexey Botchkov [ 2022-10-03 ]

mostly ok.
details discussed on slack.

Comment by Alexey Botchkov [ 2022-10-03 ]

ok with the recent version.

Comment by Marko Mäkelä [ 2022-10-04 ]

The pre MDEV-16290 syntax repeats the bug also in older versions. I’d expect that MySQL 5.6 and MariaDB Server since version 10.0 are affected (if you omit ALGORITHM=NOCOPY or replace it with ALGORITHM=INPLACE):

--source include/have_partition.inc
 
CREATE TABLE t (a INT, b INT) PARTITION BY LIST (b) (PARTITION p1 VALUES IN (1,2));
INSERT INTO t VALUES (0,1),(2,2);
 
ALTER TABLE t CHANGE b f INT, CHANGE a b INT, ALGORITHM=NOCOPY;
CHECK TABLE t;
DELETE FROM t ORDER BY b LIMIT 1;
 
# Cleanup
DROP TABLE t;

10.3 dd8833bff0af1b75e007e3db1d18debfb7c4a096

mysqltest: At line 8: query 'DELETE FROM t ORDER BY b LIMIT 1' failed: 2013: Lost connection to MySQL server during query
mysqld: /mariadb/10.3/sql/ha_partition.cc:4627: virtual int ha_partition::delete_row(const uchar*): Assertion `!error' failed.

Comment by Aleksey Midenkov [ 2022-10-05 ]

Pushed to 10.3. Any merge conflicts should be resolved in favor of bb-10.5-midenok. As well as more test cases should be added from bb-10.5-midenok.

Generated at Thu Feb 08 10:01:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.