From: Lars-Erik Bjørk
Date: June 12 2009 2:51pm
Subject: Re: Potential bug?
List-Archive: http://lists.mysql.com/falcon/764
Message-Id: <ACA40010-4905-4463-BDAC-7923B3C784FA@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; delsp=yes; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE


Pushed ...

On Jun 12, 2009, at 10:13 AM, Lars-Erik Bj=F8rk wrote:

> Yes, I will do that.
>
> It does not fix my current problems, though, but I am pretty sure =
=20
> that this 'would be' / 'is the cause of' some bug, somewhere :)
>
> /Lars
>
>
> On Jun 10, 2009, at 6:33 PM, Christopher Powers wrote:
>
>> Kevin Lewis wrote:
>>> Lars-Erik,
>>>
>>> Good catch.  This function is in used three places within =20
>>> IndexRootPage::indexMerge and nowhere else.  This might be your =
=20
>>> bug that causes badly sorted indexes.
>>>
>>> Kevin
>> I agree. There are three ::setKey() methods. Can you group them =
=20
>> together in the header and cpp file?
>>>
>>> Lars-Erik Bj=F8rk wrote:
>>>> Hi all!
>>>>
>>>> I came across the following funny snippet of code:
>>>>
>>>> void IndexKey::setKey(int offset, int length, const UCHAR *data)
>>>> {
>>>>   memcpy(key + offset, data, length);
>>>>   length =3D offset + length;
>>>> }
>>>>
>>>> I assume the writer intended to write 'keyLength =3D offset + =
=20
>>>> length'?
>>>>
>>>> Unless someone has any objections, I will push a patch for this =
=20
>>>> (without a review :) )
>>>> and hope some existing issues disappear :)
>>>>
>>>> /Lars-Erik
>>>>
>>>
>>
>
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe:    http://lists.mysql.com/falcon?unsub=3Dlars-erik.=
bjork@stripped
>