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

[hyc@symas.com]

Hallvard Breien Furuseth wrote:
> test001 still crashes if you insert
>      assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int));
> in mdb_cmp_int().
> Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...".

Not happening here, all tests pass with asserts enabled.

> I don't see "same size" in the INTEGERDUP doc, it's looser
> than for INTEGERKEY integers.  Or have I gone blind again?
> Anyway, it would be clearer to cut some doc and say data
> behave like INTEGERKEY keys.  Ignoring that, though:
>
> Looking yet again at the doc, mdb_dbi_open():INTEGERKEY
> says "typically" sizeof(int/size_t), I can't see it
> requires these sizes.  Maybe you copied that from a
> suggestion from me back when I asked for clarifications.

Probably. The point was to show the expected sizes without enumerating 
every possible C integer type that would work - e.g. unsigned int, 
unsigned long, off_t, pid_t, whatever. At some point you have to say 
"don't be an idiot."

> "keys must all be of the same size" in the doc is unclear.
> I gather it should be "... in the DB's lifetime".  But it
> can be read as "...at a given time": Write size_t-sized
> integers, empty the DB, then write int-sized integers.
> That does not work, since me_dbxs[].md_dcmp is updated.

Don't be an idiot. If no time is stated, then it's For All Time. 
Anything not called out specifically is, by definition, non-specific.

> "mc->mc_dbx->md_dcmp = mdb_cmp_clong;" looks wrong.
> That updates env->me_dbxs[], I believe.  But:
>
> If we mdb_txn_abort(), the txn has not been a no-op:
> It will require next txn and even existing txns to use
> size_t-sized INTEGERDUP data.

Good point. I've committed a revised patch to leave the mc_dbx pointer 
alone.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/