[Date Prev][Date Next]
Re: LMDB stuff
- To: email@example.com
- Subject: Re: LMDB stuff
- From: Emmanuel LÃcharny <firstname.lastname@example.org>
- Date: Mon, 03 Feb 2014 23:44:18 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VsKbhrqzIImUTe7tq2p6nLTQiIuvOLm0pcl9204LBlI=; b=mqbR+GxZkb21cqKkWwhufYRtt+CPoXF4JAPpEcHSoVBUxLftNJN31dU3vlrylOGJBw EmofczSTaiTSo8gheaziZlGnMu1uhYzu7OCYkT93VGA5waC9kOjSLPJHPtlbbE18lyG0 YbVf5PqxdbqXd+4isFab1ItR8qJR5+w2+nRSYRB56r2MuqLJYq0I02SbTsB6/C9Tukip 11/ZyRVXt946OzTzagW0ANxROlgLeTz3IgjgVzWUcZkLTTSJuIXf3URsG6e/DtnbDK4O /+GwzCQqwI/TQTXwDqq2LSQKT0NzZTo/wVxpAkcQbstsSjnEJ5qUX2LnNTZgiFaiYLRu GGWA==
- In-reply-to: <52F006AF.email@example.com>
- References: <52F006AF.firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
Le 2/3/14 10:14 PM, Howard Chu a Ãcrit :
> 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.
You have two use cases :
o when you are adding new revisions, and no new read occurs (this is the
easy use case : you can get rid of any pages being copied twice)
o when a read txn is released (now, you have to go through all the pages
that have been copied before this read txn down to the next read txn,
and remove all pages which have been copied twice, and go up to the next
read or write txn, to do the same work).