Was chatting with Emmanuel Lecharny (who is currently working on Mavibot for
ApacheDS, an MVCC backend similar to LMDB) and had an interesting realization:
we can avoid the current issue of long-lived reader txns preventing page
The key point is this - currently for any txn, we store in the freeDB a list
of the pageIDs that were freed in that txn (due to being copied or deleted).
All we need is to know that any of these pages has been copied *twice* since
the txn of the outstanding reader. At that point, any such page is so new that
the reader would never have seen it, and if no other readers are outstanding
then the page can be safely reclaimed.
Currently mavibot maintains this revision history in a dedicated Btree (much
like our freeDB but with more info contained). I'm thinking, since we're
already going to add a txnID to every page's page header, we can simply add a
2nd txnID, recording the txnID of the previous change to this page's ancestor.
Then, any page where this prevTxnID is >= the outstanding reader's txnID can
Still thinking about the actual implementation of this, it may make more sense
to store the prevTxnID in the freeDB than in each page header. Ideally we want
to be able to grab a chunk of pageIDs unambiguously, instead of having to
iterate thru each page and read its header to determine if it's safe.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Unfortunately, the current cn=config design makes it essentially impossible
to use global modules. For example, the pw-sha2 global module for adding
addtional hashing schemes cannot be used with cn=config. This is because
the olcPasswordHash value is loaded up when cn=config is bootstrapped,
prior to loading the global module. This means that the value fails sanity
checking, and slapd aborts. See also ITS#7802.
Ideas on how to address this chicken and egg issue welcome. ;)
Architect - Server
Zimbra :: the leader in open source messaging and collaboration
Yes, I know:
Set-based ACLs are slow even if one properly sets index configuration.
But I'd like to raise a discussion here whether it would be possible to improve
the performance within slapd.