Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6
-
None
Description
Note:
I've set affected version tentatively to 10.5-10.6, because the problem is visible there. But the diagnostic was only added in the 10.5 part of MDEV-17913. So, it can be a false positive in 10.5 if CHECK reports a non-existing issue, or it can be a real problem which is not visible in 10.4 due to the absence of diagnostics (or, of course it can also be a 10.5-only issue).
--source suite/encryption/include/have_file_key_management_plugin.inc
|
|
SET @aria_encrypt= @@aria_encrypt_tables; |
SET GLOBAL aria_encrypt_tables= 1; |
|
CREATE TABLE t1 (f DATE PRIMARY KEY) ENGINE=Aria; |
INSERT INTO t1 (f) VALUES ('1995-01-01'),('2000-01-01'); |
DELETE FROM t1 WHERE f = '2000-01-01'; |
OPTIMIZE TABLE t1; |
CHECK TABLE t1 EXTENDED; |
|
# Cleanup
|
DROP TABLE t1; |
SET GLOBAL aria_encrypt_tables= @aria_encrypt; |
10.5 b8fad8c6 |
CHECK TABLE t1 EXTENDED; |
Table Op Msg_type Msg_text |
test.t1 check error Page 1: Wrong LSN (3885152,0x70806be8). Current LSN is (1,0x9574) |
test.t1 check error Table is probably from another system and must be zerofilled or repaired ('REPAIR TABLE table_name') to be usable on this system |
test.t1 check error Corrupt |
The printout was added by this commit:
commit 81258f14323e1d1ad0203bae93bc55a30d47c1b3
|
Author: Monty
|
Date: Fri Apr 2 22:00:36 2021 +0300
|
|
MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work
|
Attachments
Issue Links
- relates to
-
MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work
- Closed