Bug #42652 Maria corruption after recovery: Got an error from thread_id=1, ha_maria.cc:1010
Submitted: 6 Feb 2009 15:10 Modified: 26 May 2010 17:51
Reporter: Philip Stoev Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Server: Maria storage engine Severity:S1 (Critical)
Version:6.0-maria OS:Any
Assigned to: CPU Architecture:Any
Triage: Triaged: D2 (Serious)

[6 Feb 2009 15:10] Philip Stoev 
Description:
After recovering after a workload against a partitioned table with numerous long indexes, the table becomes corrupted. CHECK TABLE reports:

# 16:52:04 090206 16:52:04 [ERROR] Got an error from thread_id=1, ha_maria.cc:1008
# 16:52:04 090206 16:52:04 [ERROR] MySQL thread id 1, query id 209 localhost 127.0.0.1 root Checking table

ANALYZE table reports:

# 16:52:04 090206 16:52:04 [ERROR] mysqld: Table './test/table100_maria_key_pk_parts_2_int_autoinc#P#p0' is marked as crashed and should be repaired
# 16:52:04 090206 16:52:04 [Note] Zerofilling table:   './test/table100_maria_key_pk_parts_2_int_autoinc'
# 16:52:04 090206 16:52:04 [Note] Zerofilling table:   './test/table100_maria_key_pk_parts_2_int_autoinc'

which is kind of scary

How to repeat:
A test case will be uploaded shortly.
[6 Feb 2009 21:19] Guilhem Bichot 
Just a detail:
- zerofilling only means that it feels the free parts of data and index pages with zeroes (for better compression) and also eliminates versioning-related information from rows/keys; the latter gains free space in the files; it makes sense when the table is imported (via binary copy or RESTORE) from another server, and is automatic.
- I don't know why it is auto-zerofilled here!!