wietse(a)porcupine.org wrote:
Wietse Venema:
>> env can be NULL. mdb_env_set_assert(env,cb) also sets a static
>> variable with the callback for the asserts which do not know of an
>> env. Could throw away that part later. Currently it only applies
>> to one assert().
>>
>> The branch also invalidates a transaction on any page allocation
>> error, since the callers do not always clean up afterwards. Too
>> aggressive, can be reverted after updating the callers. But for
>> now it means MDB_MAP_FULL & co won't let the user commit an
>> inconsistent transaction.
>
> Thanks, this is more improvement than I asked for. I don't want to
> slip my schedule, and to avoid last-minute surprises, I will postpone
> the review and impact test of these improvements after the stable
> Postfix release 2-3 weeks from today.
It looks like you are switching from a stop-gap fix (bare-bones
call-back) to a more permanent solution.
In that case I must mention again that I need to register not only
a call-back function pointer but also a void* pointer that is
returned to me at call-back time.
Getting the MDB_env at call-back time does not help me at all,
because my programs open many databases (including non-LMDB).
I made this comment to Hallvard as well. It should be:
MDB_assert_func *
mdb_env_set_assert(MDB_env *env, MDB_assert_func *func, void *info);
with the info being passed thru to the callback.
To find out which database is affected I need my own pointer to my
own (DICT) object that encapsulates the LMDB database. Then I can
decide if the problem is with a disposable cache. in which case the
program can continue with degraded performance.
Wietse
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/