From sergej.jurecko@gmail.com Thu May 28 05:27:47 2015 From: sergej.jurecko@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8156) triggering MDB_PAGE_FULL Date: Thu, 28 May 2015 05:27:45 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7006522963416591024==" --===============7006522963416591024== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --089e0160aab816893f05171d9e22 Content-Type: text/plain; charset=UTF-8 Thank you for the explanation. Sergej On Wed, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > On 27/05/15 09:00, sergej.jurecko(a)gmail.com wrote: > >> Using a dupsort and writing a large value (which is still bellow >> maxkeysize) >> will result in MDB_PAGE_FULL. >> (...) >> maxkeysize=10000 >> > > Too big MDB_MAXKEYSIZE. Its doc says: > "Keys and MDB_DUPSORT data items must fit on a node in a regular page." > > But the doc should clarify that MDB_MAXKEYSIZE can be set big enough > to break lmdb. > > Or mdb_env_open() can fail if the computed me_maxkey would be smaller. > > Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that, > and then fail if the page size would be unsupported. (MIN_PAGESIZE > can be computed at compile time, with some ugly macros.) > > lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=0. > Some time ago, that was 1/3 of the size you could reasonably use > (to allow 1 key + sub-page with 2 dupsort values), so it could make > sense to define MDB_MAXKEYSIZE above the safe max. Today lmdb > uses a sub-DB at once if a sub-page would be too small, though. > So I don't see much need to support maxkeysize > safe max. > --089e0160aab816893f05171d9e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the explanation.


Serg= ej

On We= d, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth <= ;h.b.furuseth= @usit.uio.no> wrote:
On 27/= 05/15 09:00, = sergej.jurecko(a)gmail.com wrote:
Using a dupsort and writing a large value (which is still bellow=C2=A0 maxk= eysize)
will result in MDB_PAGE_FULL.
(...)
maxkeysize=3D10000

Too big MDB_MAXKEYSIZE.=C2=A0 Its doc says:
"Keys and MDB_DUPSORT data items must fit on a node in a regular page.= "

But the doc should clarify that MDB_MAXKEYSIZE can be set big enough
to break lmdb.

Or mdb_env_open() can fail if the computed me_maxkey would be smaller.

Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that,
and then fail if the page size would be unsupported.=C2=A0 (MIN_PAGESIZE can be computed at compile time, with some ugly macros.)

lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=3D0.
Some time ago, that was 1/3 of the size you could reasonably use
(to allow 1 key + sub-page with 2 dupsort values), so it could make
sense to define MDB_MAXKEYSIZE above the safe max.=C2=A0 Today lmdb
uses a sub-DB at once if a sub-page would be too small, though.
So I don't see much need to support maxkeysize > safe max.

--089e0160aab816893f05171d9e22-- --===============7006522963416591024==--