From juerg.bircher@helmedica.com Thu Jul 30 16:02:03 2015 From: juerg.bircher@helmedica.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8181) LMDB page leaks etc when treating DBs as data Date: Thu, 30 Jul 2015 16:02:01 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6115887208527413444==" --===============6115887208527413444== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. = I really appreciate your great work. Good efficient C code is not always fo= und! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused= about your statement that most application use never subDBs? I think it is= a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function = for the main db to an integer based one opposite to the literal compare fun= ction which is the default. Therefore when opening a database by its name t= he wrong database might be returned as the integer compare function might t= hink names are equal as only 96 bits (in my function) are compared. So the = compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree= on your statement to keep things simple. I solved the problem by never usi= ng the main db so under no circumstances the database meta is corrupted. I = think the price paid for having only named databases is very cheap as I ope= n databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch --_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <86943131EABB0349A4C3B75E01000508(a)eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Howard,

I am new to lmdb. I have been working with lmdb intensively for one mo= nth. I really appreciate your great work. Good efficient C code is not alwa= ys found!

Well I like to follow up on that reported issue.

I am using multiple databases on the same environment. I was a bit con= fused about your statement that most application use never subDBs? I think = it is a great feature that helps to support multiple indexes.

I ran unintentionally into a related problem as I set the compare func= tion for the main db to an integer based one opposite to the literal compar= e function which is the default. Therefore when opening a database by its n= ame the wrong database might be returned as the integer compare function might think names are equal as on= ly 96 bits (in my function) are compared. So the compare function only comp= ares the prefix of the database names!

Maybe the database meta should be kept in a private space. But I also = agree on your statement to keep things simple. I solved the problem by neve= r using the main db so under no circumstances the database meta is corrupte= d. I think the price paid for having only named databases is very cheap as I open databases at startup and keep= the database index (dbi).

Regards

J=FCrg

Rockethealth by Helmedica AG

Web: = www.rockethealth.ch

J=FCrg Bircher=

Chief Technology = Officer<= /p>

Mail: juerg.bircher(a)helmedica.ch<= /a>

--_000_D1E06B6B7E2juergbircherhelmedicacom_-- --===============6115887208527413444==--