LMDB stuff
by Howard Chu
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
reclamation.
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
be reclaimed.
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/
8 years, 10 months
RE: slap_timestamp with microsecond granularity?
by Quanah Gibson-Mount
--On April 29, 2014 at 12:16:59 PM -0700 "Paul B. Henson" <henson(a)acm.org>
wrote:
> Even more conveniently, it looks like it's getting the microseconds value
> from a member of the op structure, the ppolicy_bind_response function in
> servers/slapd/overlays/ppolicy.c also has an op structure passed in, which
> presumably should have the same microseconds value, so it looks like it
> would be very trivial to emulate the above timestamp generating code in
> the password policy module.
As already noted by Howard, please move this discussion to the
openldap-devel list.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 10 months
cantor down?
by Quanah Gibson-Mount
Is cantor down? I can't seem to connect on port 22 or do a git pull of the
latest source.
Thanks,
Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 11 months
really ITS#4365?
by Michael Ströder
HI!
I'm trying to figure out what was recently fixed in RE24.
But this comment in CHANGES does not really match the referenced ITS:
libldap CR/LF handling (ITS#4365)
Maybe I'm overlooking something?
Ciao, Michael.
8 years, 11 months
