[email protected] 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/
