Hi Satya,
a few comments inline.
On Fri, Feb 27, 2009 at 02:35:43PM +0000, Satya B wrote:
> #At file:///home/satya/WORK/mysql-5.1-bugteam-32880/ based on
> revid:davi.arnaut@stripped
>
> 2820 Satya B 2009-02-27
> Fix for BUG#32880 - Repairing Archive table fails with internal error 144
>
> Repairing Archive table fails as the row read from the corrupted archive
> table is not equal the length at the time of insert
>
> The assertion is not valid anymore and removed it to avoid the server
> crash
I think this is not proper description for the problem.
Any statement reading corrupt archive data file
(CHECK/REPAIR/SELECT/UPDATE/DELETE) may cause assertion
failure in debug builds. This assertion has been removed
and an error is returned instead.
Also fixed that CHECK/REPAIR returns vague error message
when it mets corruption in archive data file. This is
fixed by returning proper error code.
> added:
> mysql-test/std_data/bug32880.ARN
> mysql-test/std_data/bug32880.ARZ
> mysql-test/std_data/bug32880.frm
> modified:
> mysql-test/r/archive.result
> mysql-test/t/archive.test
> storage/archive/ha_archive.cc
>
> per-file messages:
> mysql-test/r/archive.result
> modified result file for the repair table operation
> mysql-test/std_data/bug32880.ARN
> corrupted table to test check and repair table operation
> mysql-test/std_data/bug32880.ARZ
> corrupted table to test check and repair table operation
> mysql-test/std_data/bug32880.frm
> corrupted table to test check and repair table operation
Please mention that it is corrupted _archive_ table.
> mysql-test/t/archive.test
> test to check if corrupted archive table fails with error
For archive.test and archive.result I'd rather put:
A test case for BUG#32880.
...skip...
> === added file 'mysql-test/std_data/bug32880.ARN'
> Binary files a/mysql-test/std_data/bug32880.ARN 1970-01-01 00:00:00 +0000 and
> b/mysql-test/std_data/bug32880.ARN 2009-02-27 14:35:39 +0000 differ
>
> === added file 'mysql-test/std_data/bug32880.ARZ'
> Binary files a/mysql-test/std_data/bug32880.ARZ 1970-01-01 00:00:00 +0000 and
> b/mysql-test/std_data/bug32880.ARZ 2009-02-27 14:35:39 +0000 differ
>
> === added file 'mysql-test/std_data/bug32880.frm'
> Binary files a/mysql-test/std_data/bug32880.frm 1970-01-01 00:00:00 +0000 and
> b/mysql-test/std_data/bug32880.frm 2009-02-27 14:35:39 +0000 differ
I assume that these corrupt files do not have any customer data and are
relatively small.
> === modified file 'mysql-test/t/archive.test'
> --- a/mysql-test/t/archive.test 2008-03-14 16:59:03 +0000
> +++ b/mysql-test/t/archive.test 2009-02-27 14:35:39 +0000
> @@ -1599,3 +1599,20 @@ INSERT INTO t1 VALUES (NULL, NULL),(NULL
> FLUSH TABLE t1;
> SELECT * FROM t1 ORDER BY a;
> DROP TABLE t1;
> +
> +#
> +# BUG#32880 - Repairing Archive table fails with internal error 144
> +#
> +
> +# Test with an existing table which is corrupted
> +let $MYSQLD_DATADIR= `select @@datadir`;
> +copy_file std_data/bug32880.frm $MYSQLD_DATADIR/test/t1.frm;
> +chmod 0777 $MYSQLD_DATADIR/test/t1.frm;
> +copy_file std_data/bug32880.ARZ $MYSQLD_DATADIR/test/t1.ARZ;
> +chmod 0777 $MYSQLD_DATADIR/test/t1.ARZ;
> +copy_file std_data/bug32880.ARN $MYSQLD_DATADIR/test/t1.ARN;
> +chmod 0777 $MYSQLD_DATADIR/test/t1.ARN;
Why chmod here? Please remove them, unless there is really some reason
for them.
> +show create table t1;
As was requested by QA:
SHOW CREATE TABLE t1;
> +CHECK TABLE t1;
> +REPAIR TABLE t1;
> +DROP TABLE t1;
>
> === modified file 'storage/archive/ha_archive.cc'
> --- a/storage/archive/ha_archive.cc 2008-10-03 18:08:40 +0000
> +++ b/storage/archive/ha_archive.cc 2009-02-27 14:35:39 +0000
> @@ -1076,8 +1076,6 @@ int ha_archive::unpack_row(azio_stream *
>
> read= azread(file_to_read, record_buffer->buffer, row_len, &error);
>
> - DBUG_ASSERT(row_len == read);
> -
> if (read != row_len || error)
> {
> DBUG_RETURN(-1);
Though it doesn't actually relate to this bug, please return
HA_ERR_CRASHED_ON_USAGE here.
> @@ -1257,7 +1255,7 @@ int ha_archive::repair(THD* thd, HA_CHEC
> int rc= optimize(thd, check_opt);
>
> if (rc)
> - DBUG_RETURN(HA_ERR_CRASHED_ON_REPAIR);
> + DBUG_RETURN(HA_ADMIN_CORRUPT);
>
> share->crashed= FALSE;
> DBUG_RETURN(0);
Regards,
Sergey
--
Sergey Vojtovich <svoj@stripped>
MySQL AB, Software Engineer
Izhevsk, Russia, www.mysql.com