From: Lars-Erik Bjørk
Date: February 10 2009 12:16pm
Subject: Re: bug#34478
List-Archive: http://lists.mysql.com/falcon/499
Message-Id: <49917005.6080408@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

Looking at the compare methods for the IndexKey class (used in 
IndexPage::indexMerge), none of them pad the shorter key to the length 
of the longer. They only compare on record number if the keys are equal 
up to the length of the shortest, and it is partial. Otherwise it 
compares on key length.

Would this make sense for the DeferredIndex::compare methods as well? 
Skip the checkTails() calls? Or will this make types with a different 
pad character than 0x00 sort incorrectly.

The following method with the (for some reason) commented out line leads 
me to believe that wen only use 0x00 for the mentioned padding anyway:

void Field::setCollation(Collation *newCollation)
{
    collation = newCollation;
    //indexPadByte = collation->getPadChar();
    indexPadByte = 0;
}


I am not so familiar with what is the correct padding character and when 
to pad etc. in all cases for every type, although the topic is very 
fascinating ;)

Btw, Kevin, I tried removing the padding, and that seems to fix the bug 
you linked to (bug#33190), when enabling the assert again. So the bugs 
are definitively closely related.

Best,

Lars-Erik

Vladislav Vaintroub wrote:
> I guess varbinary does not have any padding and this is the clue...
>
> The compare function for index keys does not exist as of today.
>
> It could look like
>
> diff = memcmp(a, b, min(length_a,length_b));
> if (diff == 0)
>   diff = (length_a > length_b)?1: ((length_a < length_b):-1:0);
>
>
> What makes me wonder in this bug is that IndexPage is not healthy either. 
>
> This could be effect of optimization that has been in index code since ever:
> when merging a new key, use the fact that keys in log record are presorted -
>
> findInsertionPoint does not search from the start of the page, but from the
> position where prior key has been inserted.
> And if keys are wrongly presorted, IndexPage could be easily corrupted too.
>
>
>
>
>
>   
>> -----Original Message-----
>> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
>> Sent: Monday, February 09, 2009 9:46 PM
>> To: Lars-Erik Bjørk
>> Cc: FalconDev
>> Subject: Re: bug#34478
>>
>> What about making the DeferredIndex class sort things exactly like the
>> IndexKeys read from index pages?  Can it use the same compare function?
>>
>> Lars-Erik Bjørk wrote:
>>     
>>> Hi all!
>>>
>>> I don't have the the battery capacity to write a long mail now (lucky
>>> you!) :) I analyzed bug#34478 (
>>>       
>> http://bugs.mysql.com/bug.php?id=34478)
>>     
>>> which also narrows down to the use of 0x00 in index keys (this time
>>>       
>> as
>>     
>>> pad bytes in the deferred index). Does anyone have an opinion on how
>>> this bug can be avoided in a nice and correct fashion? Does it make
>>>       
>> any
>>     
>>> sense to pad with 0x00?
>>>
>>> 2 minutes capacity left, sorry the short mail, please see the report
>>>       
>> for
>>     
>>> a bit more elaborate version :)
>>>
>>> Best,
>>>
>>> Lars-Erik
>>>
>>>       
>> --
>> Falcon Storage Engine Mailing List
>> For list archives: http://lists.mysql.com/falcon
>> To unsubscribe:    http://lists.mysql.com/falcon?unsub=wlad@stripped
>>     
>
>
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe:    http://lists.mysql.com/falcon?unsub=lars-erik.bjork@stripped
>
>