Hmm well... how embarrassing. To me it seemed probable that LMDB has been designed with
these rationales in mind: one must have a clear idea of the maximum order of magnitude of
the volume to be held by the database, the database must have ACID properties, and (less
probably) a single machine will not host a lot of LMDB databases. Given that it seemed
probable that when the database is full, you probably had no choice but to fail a
transaction (in order to be consistent). But ok, that was a stupid guess and a
misunderstanding of LMDB rationales. I'm sorry; I didn't mean to offend anyone.
Anyway, thanks a lot for ITS#8324! I'll give it a try!
De : openldap-technical [mailto:firstname.lastname@example.org] De la part de
Envoyé : lundi 30 novembre 2015 20:15
À : Bruno Freudensprung <bruno.freudensprung(a)temis.com>;
Objet : Re: Growing an LMDB database after MDB_MAP_FULL
Bruno Freudensprung wrote:
I have a question regarding growing an LMDB database when a write
transaction hits MDB_MAP_FULL.
I would like to avoid defining a high mapsize value because my
application will contain many MDB_envs, and because I have Windows
(Windows allocates the whole file on the disk).
Based on the intuition that MDB_MAP_FULL should not leave the
in a weird state, I have made the following little experiment. When
MDB_MAP_FULL is encountered I tried to:
·copy the current env (mdb_env_copy) into another directory (fine: it
does not seem to contain uncommited data)
·reset the transaction « error bit » (modified LMDB code to introduce
txn->mt_flags &= ~MDB_TXN_ERROR » somewhere)
You're being stupid. You think we add error flags just for the fun of it? When you get
an error like this you must abort the current transaction. Does the documentation not
state this clearly enough?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/