From: Jorgen Loland
Date: December 17 2010 11:15am
Subject: Re: bzr commit into mysql-trunk-bugfixing branch (olav.sandstaa:3312)
Bug#58463
List-Archive: http://lists.mysql.com/commits/127172
Message-Id: <4D0B4654.6010900@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Olav,
Thank you for the patch. See comments inline
On 12/09/2010 03:06 PM, Olav Sandstaa wrote:
> #At file:///export/home/tmp/mysql2/opt-bug58463-fix1/ based on revid:tor.didriksen@stripped
>
> 3312 Olav Sandstaa 2010-12-09
> Patch for Bug#58463 Error Can't find record on SELECT with JOIN and ORDER BY
>
> This problem was caused by the server pushing down an index condition on
> the primary key as part of the optimization phase. Later, during the
> execution phase the server (due to a bug) changed to use a secondary index
> instead of the primary index for accessing the table. This made MRR fail
> in phase 3 due to not finding the expected records when retrieving them
> using the primary key due to the pushed index condition filtering them away.
>
> This problem with the server accidentally switching to using a secondary index will
> be fixed by the fix for Bug#58456.
>
> This patch contains a test case based on the bug report and an added assert to
> the DS-MRR implementation that will trigger if a similar situation should occur
> again (DS-MRR used on a secondary index while an index condition has been pushed
> on the primary index for the same handler object).
>
(...)
> === modified file 'sql/handler.cc'
> --- a/sql/handler.cc 2010-11-18 16:34:56 +0000
> +++ b/sql/handler.cc 2010-12-09 14:06:48 +0000
> @@ -4683,6 +4683,16 @@
> n_ranges, mode, buf);
> DBUG_RETURN(retval);
> }
> +
> + /*
> + This assert will hit if we have pushed an index condition to the
> + primary key index and then "changes our mind" and uses a different
> + index for retrieving data with MRR.
> + */
typo: "change our mind" and use
> + DBUG_ASSERT(!h->pushed_idx_cond ||
> + h->pushed_idx_cond_keyno == h->active_index ||
> + h->pushed_idx_cond_keyno != table->s->primary_key);
> +
Is this a problem when we switch from PK to secondary index only? Could it also
be the case that we switch from one secondary index to another secondary index?
--
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway