maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

"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+?

 - 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.]