Non-critical Bug Report

Hi.

This is a non-critical bug report, in the sense that it is not a bug that
causes data errors but is a problem that exists in MySQL. Probably it isn't
even a problem.
The point is that when I issue
restore table tablename from 'somedir'
I often get messages like this: "found wrong number of deleted records" and
so on but finally the table is repaired well. I found out that whenever I
delete a record from a table this thing takes place, while it shouldn't.
Here is the consequence:

How-To-Repeat:

1. Create a simple table
create table t(i int)

2. Insert some data into it (10 times)
insert into t values (1)

3. Delete a single record from it
delete from t limit 1

4. Back it up
backup table t to '/somedir'

5. Restore it
restore table t from '/somedir'

Then you get the error messages but the table is OK
If I delete 200 records from a table, I get 200 messages (warnings) when
restoring it but the table is still OK

We use MySQL 3.23.38 on a Linux server and MySQL 3.23.51 on a FreeBSD one
and the problem shows equally on both of them.



______________________________________
Scanned and protected by Inflex



------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12589@lists.mysql.com
To unsubscribe, e-mail

Re: Non-critical Bug Report

On Wednesday 25 September 2002 16:30, ëÕÌÁËÏ=D7 óÅÒÇ=C5=
=CA wrote:
> Hi.
>
> This is a non-critical bug report, in the sense that it is not a bug th=
at
> causes data errors but is a problem that exists in MySQL. Probably it i=
sn't
> even a problem.
> The point is that when I issue
> restore table tablename from 'somedir'
> I often get messages like this: "found wrong number of deleted records"=
and
> so on but finally the table is repaired well. I found out that whenever=
I
> delete a record from a table this thing takes place, while it shouldn't=



Thank you for the bug report. I was able to repeat the problem with our r=
ecent
4.0.4 tree, so we're likely to fix it in one of the next releases.

Also I should note this is mostly cosmetic problem - we just do not store=
index=20
what table is backed up, while at index rebuild we have an error for dele=
ted rows
which did not present in index (which are all rows in this case)=20


--=20
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Peter Zaitsev
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Moscow, Russia
<___/ www.mysql.com M: +7 095 725 4955


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12597@lists.mysql.com
To unsubscribe, e-mail

Re: Non-critical Bug Report

Hi!

>>>>> "Peter" == Peter Zaitsev writes:

Peter> On Wednesday 25 September 2002 16:30, =1B-LºãÛÐÚÞ=D2=
ÁÕàÓÕÙ wrote:=1B-A
>> Hi.
>>=20
>> This is a non-critical bug report, in the sense that it is not a bug=
that
>> causes data errors but is a problem that exists in MySQL. Probably i=
t isn't
>> even a problem.
>> The point is that when I issue
>> restore table tablename from 'somedir'
>> I often get messages like this: "found wrong number of deleted recor=
ds" and
>> so on but finally the table is repaired well. I found out that whene=
ver I
>> delete a record from a table this thing takes place, while it should=
n't.


Peter> Thank you for the bug report. I was able to repeat the problem w=
ith our recent
Peter> 4.0.4 tree, so we're likely to fix it in one of the next release=
s.

Peter> Also I should note this is mostly cosmetic problem - we just do =
not store index=20
Peter> what table is backed up, while at index rebuild we have an error=
for deleted rows
Peter> which did not present in index (which are all rows in this case)=
=20

A quick update on this; We will probably not fix this in 4.0.4 as
'backup table' and 'restore table' are mainly commands to be used
internally by replication and not really 'officially supported'
commands.

Instead we will concentrate on writing on a full hotbackup utility for
MyISAM tables in 4.1 that will run without any locking of the tables.

Regards,
Monty

--=20
For technical support contracts, goto https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Michael Widenius
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, CTO
/_/ /_/\_, /___/\___\_\___/ Helsinki, Finland
<___/ www.mysql.com

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12610@lists.mysql.com
To unsubscribe, e-mail