maria-developers team mailing list archive

["Philip Stoev" <pstoev@xxxxxxxxxxxx>]

This code was added as a fix for MySQL bug #38005 and then removed as a fix 
for bug #46639

The comment for the revision that removed the code is:

Bug#46639: 1030 (HY000): Got error 124 from storage engine on

INSERT ... SELECT ...


Problem was that when bulk insert is used on an empty table/partition, it 
disables the indexes for better performance, but in this specific case it 
also tries to read from that partition using an index, which is not possible 
since it has been disabled.


Solution was to allow index reads on disabled indexes if there are no 
records.


Also reverted the patch for bug#38005, since that was a workaround in the 
partitioning engine instead of a fix in myisam.

----- Original Message ----- 
From: "Zardosht Kasheff" <zardosht@xxxxxxxxx>
To: "Kristian Nielsen" <knielsen@xxxxxxxxxxxxxxx>
Cc: <maria-developers@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, December 08, 2010 9:47 PM
Subject: Re: [Maria-developers] problem with partitioning and our storage 
engine in 5.2


I think we found out the problem. In ha_partition.cc, in the function
ha_partition::handle_ordered_index_scan, this code was added:
   case partition_index_last:
     /*
       MyISAM engine can fail if we call index_last() when indexes disabled
       that happens if the table is empty.
       Here we use file->stats.records instead of file->records() because
       file->records() is supposed to return an EXACT count, and it can be
       possibly slow. We don't need an exact number, an approximate one- 
from
       the last ::info() call - is sufficient.
     */
     if (file->stats.records == 0)
     {
       error= HA_ERR_END_OF_FILE;
       break;

We always thought that stats.records was meant to be an estimate, and
that an estimate of 0 was ok even if the table was non-empty. We were
reporting that stats.records was 0 even though the table was
non-empty. Is this assumption wrong?

-Zardosht

On Wed, Dec 8, 2010 at 2:42 PM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Zardosht Kasheff <zardosht@xxxxxxxxx> writes:
>
> > We have been working on testing our storage engine, TokuDB, against
> > MariaDB 5.2.3, and we have encountered a problem with partitioning
> > that does not exist on MySQL 5.1, MySQL 5.5, and MariaDB 5.1.50. This
> > problem also does not exist with any other storage engine that we have
> > tried. It ONLY exists with TokuDB and MariaDB 5.2.
>
> > Here is what the test is doing:
> >
> > 1. Create a table with some partitions
> > 2. update the table
> > 3. run select max(f_int1)
> > 4. run select *
> > 5. run select max(f_int1) again.
> >
> > The problem is that the query results for 3 are incorrect, even though
> > the query results for 4 and 5 are correct. MySQL 5.1, MySQL 5.5, and
> > MariaDB 5.1 produce the correct results for 3.
> >
> > What makes this even stranger is that the query results for 4 and 5
> > are always correct.
>
> It's hard to say without any code. Can you post link to launchpad tree or
> source tarball with which to reproduce?
>
> From the information given, I would suggest to run the test 
> with --valgrind,
> in case the problem is some uninitialised memory being referenced; 
> sometimes
> Valgrind can help catch this.
>
> - Kristian.

_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp