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

[wietse@porcupine.org]

Hallvard Breien Furuseth:
> wietse@porcupine.org writes:
> >Hallvard Breien Furuseth:
> >> /** User-settable callback for assert(), called before abort()
> >>  * instead of printing the message.
> >>  *
> >>  * assert(some user errors) might be unaffected.  This hack
> >>  * should become obsolete as lmdb's error handling matures.
> >>  * @param[in] msg The assertion message, not including newline.
> >>  * @parem[in] info Currently NULL. Might change in the future.
> >>  */
> >> extern void (*mdb_assert_cb)(char *msg, void *info);
> >> 
> >> (Or maybe call it -before- printing the message, you can abort or
> >> longjmp yourself if you don't want the message.)
> > 
> > Looks good. I'll code up an example implementation to set and use
> > the callback. The "info" argument should be sufficient to figure
> > out which database is failing.
> 
> To repeat, 'info' would be NULL initially.  Does that make it useless to
> you?  Various pieces of code don't know any context of interest to the
> user anyway.

That is unhelpful, as my opens lots of databases. 

Instead I propose that for each open database I give you my function
pointer AND my context pointer. Then, you call my function with my
context pointer when there is a problem.

My program opens multiple databases. It is useless if you pass me
your LMDB handle, as I now have to find out a) which of all my open
databases is LMDB and b) which of those LMDB databases is messed up.
That totally breaks all abstractions.

> I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that
> compiles so it can report env, txn, dbi.  Howard, should I do that?

That was my idea. Allow me to code up an example, it is simpler
than arguing in the abstract.

	Wietse