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

[h.b.furuseth@usit.uio.no]

Wietse Venema writes:
> (...)
> A few alternatives:
> 
> - When a request fails, return a distinct error code such as 
>   MDB_PANIC, and allow the application to look up the text for the
>   error.       

For internal errors, yes.  It'll take a fair amount of work to get
there.  And I don't expect ldmb to become enthusiastic at catching
user errors, so those may cause crashes or other misbehavior
anyway.  After all you can disable asserts with NDEBUG, but then
you may get e.g. NULL dereferences instead.

> - Invoke an application call-back function with the error code and 
>   problem description text.  If the error code is MDB_PANIC then
>   the application knows that it needs to make final arrangements.

Sounds good to me for now, since it doesn't mean walking all over
the code.  mdb.c can just #define its own assert().  No error
code, the context is just "we're about to abort" and I don't know
of other planned callbacks which the code would help.

/** 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.)

> The second option preserves 100% backwards compatibility. The first
> option may cause functions to return a result that they didn't
> return previously.

This is about situations where mdb didn't return at all, so
compatibility with old behavior will rarely be a problem with new
error codes.

-- 
Hallvard