Re: (ITS#8117) Bugs related to key-size in lmdb and backend

[leo@yuriev.ru]

29.04.2015 19:35, Howard Chu пиÑ?еÑ?:
> Leonid Yuriev wrote:
>> this is enough:
>> - add assert(a->mv_key_size == sizeof(size_t)) into mdb_cmp_long()
>> - make all test
>> - see a coredump
>
> OK, fixed in git. For the record, this affected MDB_INTEGERDUP, not 
> MDB_INTEGERKEY.
>
>>>> 3) lmdb-backend:
>>>> AttributeDescription->ad_type->sat_equality->smr_indexer()
>>>> could generate a 5-byte sized ks.s. I can just imagine what this can
>>>> create a
>>>> many problems. For instance, when I adds the control for key size, it
>>>> breaks
>>>> test017-syncreplication-refresh. But I am not tested more.
>>>
>>> Not a bug, indexer keys are padded to 8 bytes.
>>
>> There is just NOT padded, I am sure.
>> Also this is reason for unaligned-access in mdb_cmp_int() and
>> mdb_cmp_long().
>> It is similar to reproduce, just assert + make test.
>
> Ah yes, the padding is currently only done on platforms that don't 
> allow unaligned access to ints (e.g. Sparc)
>
> git rev e2a7617d17368b5787fc24fbd017623d00fe162b
>
>> Seems that bugs together could break ordering of entries, this is
>> detected by loop over all entries with mdb_cursor_get(..., MDB_NEXT) and
>> comparing keys from previous step.
>> All of this I was found today, during developing a mdb_chk tool.

Yes,  I was made same local changes few hours ago.
This fixs miss-call for mdb_cmp_long().

But what about 5-bytes keys from indexer?
- How ones should be compared, as a 4-byte int without MSB, or as a 
padded 8-byte long?
- Where is the padding code?

Leonid.