Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record

[hyc@symas.com]

wietse@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/