maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #03783
Re: problem with partitioning and our storage engine in 5.2
Kristian Nielsen wrote:
> "Philip Stoev" <pstoev@xxxxxxxxxxxx> writes:
>
>> This code was added as a fix for MySQL bug #38005 and then removed as
>> a fix for bug #46639
>
> Yes.
>
> Turns out that the removal part of Bug#46639 was lost in MariaDB in this
> merge:
>
> revno: 2732 [merge]
> revision-id: igor@xxxxxxxxxxxx-20091112043128-yd6odg8zr5ribjal
> parent: psergey@xxxxxxxxxxxx-20091104224158-nk2s2luvlqwa02bl
> parent: igor@xxxxxxxxxxxx-20091110023239-vgttyweq2qmh0y25
> committer: Igor Babaev <igor@xxxxxxxxxxxx>
> branch nick: maria-5.2-vcol
> timestamp: Wed 2009-11-11 20:31:28 -0800
> message:
> Merge of the patch introducing virtual columns into maria-5.2
>
> This merge gives the following conflict (and two more like it) in
> sql/ha_partition.cc:
>
> <<<<<<< TREE
> /*
> MyISAM engine can fail if we call index_first() 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;
> }
> error= file->ha_index_first(buf);
> ||||||| BASE-REVISION
> /* MyISAM engine can fail if we call index_first() 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;
> }
> error= file->index_first(buf);
> =======
> error= file->index_first(buf);
>>>>>>>> MERGE-SOURCE
>
> In MariaDB 5.2, these conflicts were resolved by keeping the lines deleted in
> the patch, this reverting this part of the patch for Bug#46639.
>
> Igor, did you deliberately revert the of the patch like this, or is it just a
> mistake during merge?
>
> If a mistake, I can push a correction for this to 5.2.
>
> If deliberate, should the reverting also be done in MariaDB 5.1, or is it only
> necessary for 5.2+?
Probably it was a mistake.
Regards,
Igor.
>
> - Kristian.
>
> [Note that for the tokudb problem, I believe they still need to fix their
> engine to not return zero estimate as per comments in handler.h. This appears
> to be just a symptom.]
References