[MDEV-18221] Failed to execute action for entry = ... from ddl log upon normal shutdown while running ALTER .. PARTITION Created: 2019-01-13  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Partitioning
Affects Version/s: 10.3, 10.4
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-12348 Cannot reorganize partitions after up... Closed
relates to MDEV-18139 ALTER IGNORE ... ADD FOREIGN KEY ... ... Closed

 Description   

Notes:

  • The test case is for reproducing purposes only, don't put it into the regression suite as is.
  • The last statement is intentionally written with --send, so that the test case finishes while it's still running.
  • Run in MTR with --repeat=N if it doesn't fail right away.
  • Don't switch off check-testcases or warnings while running MTR. Somehow with this testcase they are important (although the failure has been seen without either of them).
  • Sometimes the test starts failing more readily with the InnoDB errors mentioned below. It just needs to be re-run again (possibly many times).
  • I've set affected versions to 10.3+, as I couldn't reproduce it on 10.2 and earlier, but it doesn't mean it's not there. Earlier versions sometimes fail with the InnoDB errors.
  • We had before an external complaint about a similar error, but in somewhat different circumstances: MDEV-12348. It might be related. We couldn't reproduce it back then.

--source include/have_partition.inc
--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT, b INT NOT NULL,KEY (b)) 
  ENGINE=InnoDB 
  PARTITION BY LIST (a) (
    PARTITION p0 VALUES IN (8,NULL),
    PARTITION p1 VALUES IN (9,7,1),
    PARTITION p2 VALUES IN (3,6,2),
    PARTITION p3 VALUES IN (5,0,4)
 );
INSERT INTO t1 VALUES 
(7,1),(6,9),(5,7),(7,5),(3,4),(4,5),(3,6),(8,9),(2,8),(5,4),(2,4),(6,7),
(6,7),(9,1),(4,7),(7,0),(7,2),(5,8),(7,1),(3,7),(3,2),(5,1),(5,0),(3,1),
(9,3),(5,7),(6,1),(0,2),(4,4),(3,3),(9,2),(5,3),(9,9),(8,2),(5,6),(3,6),
(0,7),(9,2),(1,8),(9,6),(7,3),(0,0),(0,7),(8,4),(2,4),(5,9),(8,4),(8,9),
(5,6),(5,3),(1,5),(1,3),(5,2),(5,7),(4,8),(2,8),(9,3),(0,9),(1,9),(0,4),
(3,5),(3,8),(0,5),(3,5),(9,0),(4,0),(3,0),(1,5);
INSERT INTO t1 SELECT * FROM t1;
INSERT INTO t1 SELECT * FROM t1;
INSERT INTO t1 SELECT * FROM t1;
--connect (con1,localhost,root,,)
--send
  ALTER TABLE t1 REBUILD PARTITION p1,p2,p3;

10.3 82490a97db

***Warnings generated in error logs during shutdown after running tests: bug.ddllog5
 
2019-01-13 14:37:20 10 [ERROR] Failed to execute action for entry = 5 from ddl log

Alternative InnoDB failure:

10.3 82490a97db

***Warnings generated in error logs during shutdown after running tests: bug.ddllog5
 
2019-01-13 14:38:06 10 [ERROR] InnoDB: Possible reasons:
2019-01-13 14:38:06 10 [ERROR] InnoDB: (1) Table rename would cause two FOREIGN KEY constraints to have the same internal name in case-insensitive comparison.
2019-01-13 14:38:06 10 [ERROR] InnoDB: (2) Table `test`.`t1` /* Partition `p3` */ exists in the InnoDB internal data dictionary though MySQL is trying to rename table `test`.`t1` /* Temporary Partition `p3` */ to it. Have you deleted the .frm file and not used DROP TABLE?
2019-01-13 14:38:06 10 [ERROR] InnoDB: If table `test`.`t1` /* Partition `p3` */ is a temporary table #sql..., then it can be that there are still queries running on the table, and it will be dropped automatically when the queries end. You can drop the orphaned table inside InnoDB by creating an InnoDB table with the same name in another database and copying the .frm file to the current database. Then MySQL thinks the table exists, and DROP TABLE will succeed.


Generated at Thu Feb 08 08:42:25 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.