Bug in mysql-4.1 with old (from 4.0) frm format

Hi,

I hit an annoying bug which seems to happen only with old version of frm
file (from mysql 4.0).

How-to-repeat:

mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT 20;
Empty set (0.05 sec)

mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
+-------+---------------------+--------+------------+
| topic | date | pseudo | numreponse |
+-------+---------------------+--------+------------+
| 0 | 0000-00-00 00:00:00 | joce | 2788 |
+-------+---------------------+--------+------------+
1 row in set (0.01 sec)

I've uploaded the table in support.mysql.com/pub/mysql/secret/search.tar.gz

Regards,
Jocelyn


------------------------------------------------------------ ---------
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-thread12733@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

joce writes:
> Hi,
>
> I hit an annoying bug which seems to happen only with old version of frm
> file (from mysql 4.0).
>
> How-to-repeat:
>
> mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT 20;
> Empty set (0.05 sec)
>
> mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
> +-------+---------------------+--------+------------+
> | topic | date | pseudo | numreponse |
> +-------+---------------------+--------+------------+
> | 0 | 0000-00-00 00:00:00 | joce | 2788 |
> +-------+---------------------+--------+------------+
> 1 row in set (0.01 sec)
>
> I've uploaded the table in support.mysql.com/pub/mysql/secret/search.tar.gz
>
> Regards,
> Jocelyn
>

Hi!

I have tested the above with latest 4.0 pull and it worked just fine.

I only had to change the above 'joce' condition to the one that would
produce some rows in the result set.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ 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-thread12755@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Hi,

The problem occurs with MySQL 4.1, not with MySQL 4.0, which works just fine
:)

Regards,
Jocelyn
----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc:
Sent: Wednesday, October 16, 2002 8:31 PM
Subject: Re: Bug in mysql-4.1 with old (from 4.0) frm format


> joce writes:
> > Hi,
> >
> > I hit an annoying bug which seems to happen only with old version of frm
> > file (from mysql 4.0).
> >
> > How-to-repeat:
> >
> > mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT
20;
> > Empty set (0.05 sec)
> >
> > mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
> > +-------+---------------------+--------+------------+
> > | topic | date | pseudo | numreponse |
> > +-------+---------------------+--------+------------+
> > | 0 | 0000-00-00 00:00:00 | joce | 2788 |
> > +-------+---------------------+--------+------------+
> > 1 row in set (0.01 sec)
> >
> > I've uploaded the table in
support.mysql.com/pub/mysql/secret/search.tar.gz
> >
> > Regards,
> > Jocelyn
> >
>
> Hi!
>
> I have tested the above with latest 4.0 pull and it worked just fine.
>
> I only had to change the above 'joce' condition to the one that would
> produce some rows in the result set.
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ 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-thread12766@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Jocelyn Fournier writes:
> Hi,
>
> The problem occurs with MySQL 4.1, not with MySQL 4.0, which works just fine
> :)
>
> Regards,
> Jocelyn

OK.

I can re-check it with 4.1, but could you upload a table that exactly
matches the output you reported ??

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ 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-thread12773@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Hi,

The table I uploaded correspond exactly to the output I reported :

[root@forum] /home/mysql/taist1> ls -la
<13:56:50
total 5450
drwxr-sr-x 2 mysql mysql 224 Oct 17 13:56 .
drwxr-sr-x 8 mysql mysql 584 Oct 17 13:54 ..
-rw-r--r-- 1 mysql mysql 1309284 Oct 17 13:54 search.tar.gz
-rw-rw---- 1 mysql mysql 1999404 Oct 17 13:56
searchjoinhardwarefr8.MYD
-rw-rw---- 1 mysql mysql 2252800 Oct 17 13:56
searchjoinhardwarefr8.MYI
-rw-rw---- 1 mysql mysql 8644 Oct 15 17:06
searchjoinhardwarefr8.frm

[root@forum] /home/mysql/taist1> mysql -uroot -p
<13:56:53
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 82149 to server version: 4.1.0-alpha

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> flush tables;
Query OK, 0 rows affected (0.18 sec)
mysql> use taist1
Database changed
mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT 20;
Empty set (0.00 sec)

mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
+-------+---------------------+--------+------------+
| topic | date | pseudo | numreponse |
+-------+---------------------+--------+------------+
| 0 | 0000-00-00 00:00:00 | joce | 2788 |
+-------+---------------------+--------+------------+
1 row in set (0.00 sec)

As you can see, the SELECT * query return a row with pseudo set to "joce"
whereas with the WHERE condition, no row is returned.

myisamchk doesn't see any problem :

[root@forum] /home/mysql/taist1> myisamchk -o searchjoinhardwarefr8.MYI
<14:03:28
- recovering (with keycache) MyISAM-table 'searchjoinhardwarefr8.MYI'
Data records: 39204

However, I noticed something really odd.
I tested this table under MySQL-4.0.5, and noticed the problem was the same.

So I tried the following :

mysql> ALTER TABLE searchjoinhardwarefr8 DROP PRIMARY KEY, ADD PRIMARY KEY
(date,numreponse,topic);
Query OK, 39204 rows affected (2.00 sec)
Records: 39204 Duplicates: 0 Warnings: 0

(ie, I regenerated the primary key)

And then, it works perfectly !?

mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT
0,20;
+-------+
| topic |
+-------+
| 1757 |
| 2228 |
| 2228 |
| 2148 |
| 2148 |
| 2431 |
| 2464 |
| 2431 |
| 2431 |
| 2431 |
| 2431 |
| 2721 |
| 2754 |
| 2754 |
| 2754 |
| 2829 |
| 2754 |
| 2754 |
| 2754 |
| 2754 |
+-------+
20 rows in set (0.00 sec)

[root@forum] /home/mysql/taist1> ls -la
<14:08:01
total 6218
drwxr-sr-x 2 mysql mysql 224 Oct 17 14:06 .
drwxr-sr-x 8 mysql mysql 584 Oct 17 13:54 ..
-rw-r--r-- 1 mysql mysql 1309284 Oct 17 13:54 search.tar.gz
-rw-rw---- 1 mysql mysql 1999404 Oct 17 14:06
searchjoinhardwarefr8.MYD
-rw-rw---- 1 mysql mysql 3036160 Oct 17 14:06
searchjoinhardwarefr8.MYI
-rw-rw---- 1 mysql mysql 8660 Oct 17 14:06
searchjoinhardwarefr8.frm

You can see the index file has a completely different size than before.
(I tested this method with MySQL-4.0.5 with the same behaviour, excepted of
course the size of the frm file)

So my question is : why myisamchk is not able to repair this table (and do
not even see it is broken) obviously broken ? (the odd thing is all my
searchjoinhardwarefr was broken in the same way, and I repaired it with the
same method (regenerating manually the primary key)).

Regards,
Jocelyn

----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc:
Sent: Thursday, October 17, 2002 1:51 PM
Subject: Re: Bug in mysql-4.1 with old (from 4.0) frm format


> Jocelyn Fournier writes:
> > Hi,
> >
> > The problem occurs with MySQL 4.1, not with MySQL 4.0, which works just
fine
> > :)
> >
> > Regards,
> > Jocelyn
>
> OK.
>
> I can re-check it with 4.1, but could you upload a table that exactly
> matches the output you reported ??
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ 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-thread12774@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Jocelyn Fournier writes:
> Hi,
>
> The table I uploaded correspond exactly to the output I reported :
>
> [root@forum] /home/mysql/taist1> ls -la
> <13:56:50
> total 5450
> drwxr-sr-x 2 mysql mysql 224 Oct 17 13:56 .
> drwxr-sr-x 8 mysql mysql 584 Oct 17 13:54 ..
> -rw-r--r-- 1 mysql mysql 1309284 Oct 17 13:54 search.tar.gz
> -rw-rw---- 1 mysql mysql 1999404 Oct 17 13:56
> searchjoinhardwarefr8.MYD
> -rw-rw---- 1 mysql mysql 2252800 Oct 17 13:56
> searchjoinhardwarefr8.MYI
> -rw-rw---- 1 mysql mysql 8644 Oct 15 17:06
> searchjoinhardwarefr8.frm
>

Ok,

I will re-test it and will let you know the results.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ 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-thread12775@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Jocelyn Fournier writes:
> Hi,
>

[skip

> mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT 20;
> Empty set (0.00 sec)
>
> mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
> +-------+---------------------+--------+------------+
> | topic | date | pseudo | numreponse |
> +-------+---------------------+--------+------------+
> | 0 | 0000-00-00 00:00:00 | joce | 2788 |
> +-------+---------------------+--------+------------+
> 1 row in set (0.00 sec)
>
> As you can see, the SELECT * query return a row with pseudo set to "joce"
> whereas with the WHERE condition, no row is returned.
>
> myisamchk doesn't see any problem :
>
> [root@forum] /home/mysql/taist1> myisamchk -o searchjoinhardwarefr8.MYI
> <14:03:28
> - recovering (with keycache) MyISAM-table 'searchjoinhardwarefr8.MYI'
> Data records: 39204
>
> However, I noticed something really odd.
> I tested this table under MySQL-4.0.5, and noticed the problem was the same.
>


Hi!

I have thoroughly tested your tested your test case with both 4.0.5
(as you reported problem with that version too) and with 4.1.0.

Problem stems from the fact that information on indices as found in
..frm file is in total disagreement with index info as found in .MYI
file, which can cause very severe problems.

Here is info from myisamchk -dvv :


MyISAM file: searchjoinhardwarefr8.MYI
Record format: Fixed length
Character set: latin1 (8)
File-version: 1
Creation time: 2002-06-27 0:23:24
Recover time: 2002-10-15 18:08:58
Status: checked
Data records: 39204 Deleted blocks: 0
Datafile parts: 39204 Deleted data: 0
Datafile pointer (bytes): 4 Keyfile pointer (bytes): 3
Datafile length: 1999404 Keyfile length: 2252800
Max datafile length: 219043332094 Max keyfile length: 17179868159
Recordlength: 51

table description:
Key Start Len Index Type Rec/key Root Blocksize
1 13 35 unique char packed stripped 18 1562624 1024
5 8 ulonglong 1
48 4 unsigned long 1
2 3 uint24 1
2 48 4 unique unsigned long 1 456704 1024
3 2 3 multip. uint24 20 712704 1024

Field Start Length Nullpos Nullbit Type
1 1 1
2 2 3
3 5 8
4 13 35
5 48 4


And here is info from SHOW INDEX .........
+-----------------------+------------+------------+--------- -----+-------------+-----------+-------------+----------+--- -----+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-----------------------+------------+------------+--------- -----+-------------+-----------+-------------+----------+--- -----+------+------------+---------+
| searchjoinhardwarefr8 | 0 | PRIMARY | 1 | date | A | 2178 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | PRIMARY | 2 | numreponse | A | 39204 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | PRIMARY | 3 | topic | A | 39204 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | pseudo | 1 | pseudo | A | 39204 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | pseudo | 2 | date | A | 39204 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | pseudo | 3 | numreponse | A | 1960 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | pseudo | 4 | topic | A | 0 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 0 | numreponse | 1 | numreponse | A | 0 | NULL | NULL | | BTREE | |
| searchjoinhardwarefr8 | 1 | topic | 1 | topic | A | 0 | NULL | NULL | | BTREE | |
+-----------------------+------------+------------+--------- -----+-------------+-----------+-------------+----------+--- -----+------+------------+---------+


As you can see differences are huge and unsurmountable.

A fix, with both 4.0.5 and 4.1.0 is quite simple. Use:

repair table searchjoinhardwarefr8 use_frm;

In both 4.0 and 4.1 that fixes a problem permanently.

We would very much like to know, how did you manage to achive the
above ??

Was it some partial backup, failed ALTER TABLE , or what ???

What we would like to see, however, is a detailed and repeatable case,
which would enable us to prevent the above situations of happening in
the future.

Thanks a lot in advance.

--
Regards,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ 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-thread12799@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Hi,

Thanks for the informations. We will manage to find out what causes the
corruption.
Is this possible to include the frm regeneration in myisamchk or mysqlcheck
?

Regards,
Jocelyn

----- Original Message -----
From: "Sinisa Milivojevic"
To:
Cc:
Sent: Saturday, October 19, 2002 7:19 PM
Subject: Re: Bug in mysql-4.1 with old (from 4.0) frm format


> Jocelyn Fournier writes:
> > Hi,
> >
>
> [skip
>
> > mysql> SELECT topic FROM searchjoinhardwarefr8 WHERE pseudo='joce' LIMIT
20;
> > Empty set (0.00 sec)
> >
> > mysql> SELECT * FROM searchjoinhardwarefr8 LIMIT 1;
> > +-------+---------------------+--------+------------+
> > | topic | date | pseudo | numreponse |
> > +-------+---------------------+--------+------------+
> > | 0 | 0000-00-00 00:00:00 | joce | 2788 |
> > +-------+---------------------+--------+------------+
> > 1 row in set (0.00 sec)
> >
> > As you can see, the SELECT * query return a row with pseudo set to
"joce"
> > whereas with the WHERE condition, no row is returned.
> >
> > myisamchk doesn't see any problem :
> >
> > [root@forum] /home/mysql/taist1> myisamchk -o searchjoinhardwarefr8.MYI
> > <14:03:28
> > - recovering (with keycache) MyISAM-table 'searchjoinhardwarefr8.MYI'
> > Data records: 39204
> >
> > However, I noticed something really odd.
> > I tested this table under MySQL-4.0.5, and noticed the problem was the
same.
> >
>
>
> Hi!
>
> I have thoroughly tested your tested your test case with both 4.0.5
> (as you reported problem with that version too) and with 4.1.0.
>
> Problem stems from the fact that information on indices as found in
> .frm file is in total disagreement with index info as found in .MYI
> file, which can cause very severe problems.
>
> Here is info from myisamchk -dvv :
>
>
> MyISAM file: searchjoinhardwarefr8.MYI
> Record format: Fixed length
> Character set: latin1 (8)
> File-version: 1
> Creation time: 2002-06-27 0:23:24
> Recover time: 2002-10-15 18:08:58
> Status: checked
> Data records: 39204 Deleted blocks: 0
> Datafile parts: 39204 Deleted data: 0
> Datafile pointer (bytes): 4 Keyfile pointer (bytes): 3
> Datafile length: 1999404 Keyfile length: 2252800
> Max datafile length: 219043332094 Max keyfile length: 17179868159
> Recordlength: 51
>
> table description:
> Key Start Len Index Type Rec/key Root
Blocksize
> 1 13 35 unique char packed stripped 18 1562624
1024
> 5 8 ulonglong 1
> 48 4 unsigned long 1
> 2 3 uint24 1
> 2 48 4 unique unsigned long 1 456704
1024
> 3 2 3 multip. uint24 20 712704
1024
>
> Field Start Length Nullpos Nullbit Type
> 1 1 1
> 2 2 3
> 3 5 8
> 4 13 35
> 5 48 4
>
>
> And here is info from SHOW INDEX .........
>
+-----------------------+------------+------------+--------- -----+----------
---+-----------+-------------+----------+--------+------+--- ---------+------
---+
> | Table | Non_unique | Key_name | Seq_in_index |
Column_name | Collation | Cardinality | Sub_part | Packed | Null |
Index_type | Comment |
>
+-----------------------+------------+------------+--------- -----+----------
---+-----------+-------------+----------+--------+------+--- ---------+------
---+
> | searchjoinhardwarefr8 | 0 | PRIMARY | 1 | date
| A | 2178 | NULL | NULL | | BTREE |
|
> | searchjoinhardwarefr8 | 0 | PRIMARY | 2 |
numreponse | A | 39204 | NULL | NULL | | BTREE
| |
> | searchjoinhardwarefr8 | 0 | PRIMARY | 3 | topic
| A | 39204 | NULL | NULL | | BTREE |
|
> | searchjoinhardwarefr8 | 0 | pseudo | 1 | pseudo
| A | 39204 | NULL | NULL | | BTREE |
|
> | searchjoinhardwarefr8 | 0 | pseudo | 2 | date
| A | 39204 | NULL | NULL | | BTREE |
|
> | searchjoinhardwarefr8 | 0 | pseudo | 3 |
numreponse | A | 1960 | NULL | NULL | | BTREE
| |
> | searchjoinhardwarefr8 | 0 | pseudo | 4 | topic
| A | 0 | NULL | NULL | | BTREE |
|
> | searchjoinhardwarefr8 | 0 | numreponse | 1 |
numreponse | A | 0 | NULL | NULL | | BTREE
| |
> | searchjoinhardwarefr8 | 1 | topic | 1 | topic
| A | 0 | NULL | NULL | | BTREE |
|
>
+-----------------------+------------+------------+--------- -----+----------
---+-----------+-------------+----------+--------+------+--- ---------+------
---+
>
>
> As you can see differences are huge and unsurmountable.
>
> A fix, with both 4.0.5 and 4.1.0 is quite simple. Use:
>
> repair table searchjoinhardwarefr8 use_frm;
>
> In both 4.0 and 4.1 that fixes a problem permanently.
>
> We would very much like to know, how did you manage to achive the
> above ??
>
> Was it some partial backup, failed ALTER TABLE , or what ???
>
> What we would like to see, however, is a detailed and repeatable case,
> which would enable us to prevent the above situations of happening in
> the future.
>
> Thanks a lot in advance.
>
> --
> Regards,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ 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-thread12799@lists.mysql.com
> To unsubscribe, e-mail
>
>


------------------------------------------------------------ ---------
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-thread12801@lists.mysql.com
To unsubscribe, e-mail

Re: Bug in mysql-4.1 with old (from 4.0) frm format

Hi!

On Oct 20, Jocelyn Fournier wrote:
> Hi,
>
> Is this possible to include the frm regeneration in myisamchk or
> mysqlcheck ?

In mysqlcheck - yes (thanks for the hint), in myisamchk - no.

Regards,
Sergei

--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/

------------------------------------------------------------ ---------
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-thread12809@lists.mysql.com
To unsubscribe, e-mail