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=1
>>
>
>
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
>
>
