[MDEV-6500] Stale data returned after TRUNCATE PARTITION operation Created: 2014-07-28  Updated: 2015-06-04  Resolved: 2015-06-04

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Query Cache
Affects Version/s: 5.5.37-galera, 5.5.38
Fix Version/s: 5.5.44

Type: Bug Priority: Major
Reporter: Stuart Shelton Assignee: Vicențiu Ciorbaru
Resolution: Fixed Votes: 0
Labels: partitioning, querycache
Environment:

Ubuntu 14.04 LTS x86_64


Sprint: 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.



 Comments   
Comment by Elena Stepanova [ 2014-08-12 ]

Reproducible as described on the current 5.5 tree.

Could not reproduce on 10.0 on whatever reason, but it doesn't mean it's actually fixed in 10.0.

Could not reproduce on MySQL, possibly due to this radical change: http://bugs.mysql.com/bug.php?id=53775 .

Comment by Oleksandr Byelkin [ 2015-06-04 ]

OK to push. Thank you!

Comment by Vicențiu Ciorbaru [ 2015-06-04 ]

Fixed with:
https://github.com/MariaDB/server/commit/a477cd175476b26e5bc0090b580e9b590b17e29a

Generated at Thu Feb 08 07:12:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.