Bug #12296 | CHECKSUM TABLE reports 0 for the table | ||
---|---|---|---|
Submitted: | 1 Aug 2005 9:33 | Modified: | 28 Sep 2005 2:10 |
Reporter: | Victoria Reznichenko | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 4.1 from BK | OS: | Linux (linux) |
Assigned to: | Ingo Strüwing | CPU Architecture: | Any |
[1 Aug 2005 9:33]
Victoria Reznichenko
[11 Aug 2005 11:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/28150
[11 Aug 2005 11:54]
Ingo Strüwing
This fix implies that checksums calculated with the new MySQL version may differ from older checksums on the same table if there are deleted records in the table (which is quite probable). If users stored the old checksum values to detect table changes, they should check the tables before upgrading and calculate new values after upgrading. If necessary, measures need to be taken that noone can change the tables in between.
[29 Aug 2005 15:08]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/28982
[30 Aug 2005 12:41]
Ingo Strüwing
Pushed to 4.1.15 and 5.0.12. Docs team, please observe my last comment to this bug report.
[13 Sep 2005 22:36]
Mike Hillyer
Documented in 5.0.12 and 4.1.15 changelogs: <listitem> <para> <literal>CHECKSUM TABLE</literal> command returned <literal>0</literal> for tables with deleted rows. After upgrading, users who used stored checksum information to detect table changes should rebuild their checksum data. (Bug #12296) </para> </listitem>