Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.37-galera, 5.5.38
-
Ubuntu 14.04 LTS x86_64
-
5.5.44
Description
MariaDB 5.5.38-galera, from MariaDB-hosted apt repo.
After an "ALTER TABLE ... TRUNCATE PARTITION" operation on a LIST partition, a query against the table returns data which has been removed:
CREATE TABLE `test` (
|
`uniqueId` INT NOT NULL,
|
`partitionId` INT NOT NULL,
|
PRIMARY KEY (`uniqueId`,`partitionId`)
|
) ENGINE=InnoDB PARTITION BY LIST (partitionId) (
|
PARTITION p01 VALUES IN (1),
|
PARTITION p02 VALUES IN (2)
|
);
|
|
|
INSERT INTO `test`(`uniqueId`,`partitionId`) VALUES(407237055, 2);
|
|
|
SELECT * FROM `test`;
|
-- Returns 1 row
|
SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS FROM information_schema.PARTITIONS where TABLE_NAME = 'test';
|
-- Confirms 1 row in partition 'p02'
|
ALTER TABLE `test` TRUNCATE PARTITION `p02`;
|
-- Query OK
|
SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS FROM information_schema.PARTITIONS where TABLE_NAME = 'test';
|
-- Both zero
|
SELECT * FROM `test`;
|
-- Still returns 1 row(!!)
|
SELECT SQL_CACHE * FROM `test`;
|
-- Correctly returns zero rows
|
SELECT SQL_NO_CACHE * FROM `test`;
|
-- Correctly returns zero rows
|
A colleague raised this issue with me, and I have been able to reproduce by the above method. When I tried with a RANGE partition rather than a LIST partition, I then saw the correct results whereas my colleague still reports seeing the same incorrect behaviour as above, with the different partitioning method. This may suggest that the issue is non-deterministic.