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 (
> > which also narrows down to the use of 0x00 in index keys (this time
> > 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
> > sense to pad with 0x00?
> > 2 minutes capacity left, sorry the short mail, please see the report
> > 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