openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7665) LMDB: Documentation issue or mistake: MDB_NOMETASYNC vs MDB_CREATE
by h.b.furuseth＠usit.uio.no 28 Dec '13

28 Dec '13

Salvador Ortiz writes: > The documentation states that the Environment's flags should not overlap with > the Database's ones, but MDB_NOMETASYNC and MDB_CREATE share the same value. That doc is a current implementation detail for liblmdb developers adding new flags. I should not have put it in ldmb.h. I'll drop it and add an #if/#error check in mdb.c instead. -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by hyc＠symas.com 24 Dec '13

24 Dec '13

h.b.furuseth(a)usit.uio.no wrote: > This was fixed in LMDB 0.9.9, except: If both O_DIRECT and > F_NOCACHE are #defined, both are used. Looks a bit strange. > Maybe just one should be used in that case. (Which?) Also I'm > still wondering if env_open needs to fail if F_NOCACHE fails. > > Anyway, maybe it should be something like this. The "else {}" > is in case O_DIRECT is an unsupported dummy definiton: Isn't that in the wrong order then? What you suggest here will use O_DIRECT even if it's a dummy. I don't see any reason to fail the operation. They just want to make a copy/backup; even if the optimization of avoiding pollution of the buffer cache can't be done, they still want the copy to happen. > #ifdef O_DIRECT > if ((rc = fcntl(newfd, F_GETFL)) != -1) > (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); > else > #endif > { > #ifdef F_NOCACHE /* __APPLE__ */ > (void) fcntl(newfd, F_NOCACHE, 1); > #endif > } > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7772) liblmdb sub-page growth when adding existing data
by h.b.furuseth＠usit.uio.no 23 Dec '13

23 Dec '13

Full_Name: Hallvard B Furuseth Version: mdb.master, 4c8f57615c5ca7b014c038e59c1045182e74f5ad OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-growth-131223.c Submission from: (NULL) (81.191.45.35) Submitted by: hallvard A non-LEAF2 sub-page grows if you put() a data item which already exists. The space remains unused while the sub-page exists. (A LEAF2 page grows reusable space, and only if it is full.) Demo program enclosed. Edit mdb.c to set mdb_debug=1 and build with -DMDB_DEBUG. Watch the 1st DPRINTF() in mdb_node_add(): bash$ ./a.out 2>&1 | perl -lne '/add to (.*) key size/ && print $1' leaf page 2 index 0, data size 404 # node with 1st item leaf page 2 index 0, data size 840 # convert to sub-page for 2nd item leaf sub-page 2 index 0, data size 0 leaf sub-page 2 index 1, data size 0 leaf page 2 index 0, data size 1250 # space for re-adding 2nd item leaf page 2 index 0, data size 1660 # space for re-adding 2nd item leaf page 2 index 0, data size 48 # ...too big, moved to sub-DB. Fix: lmdb could position cursor+xcursor fully before spill/touch, with an MDB_GET_BOTH variant which returns different codes for "no such key" and "no such data". And position it before MDB_MULTIPLE loops up. The current comparisons to see if the data item exists, go away. Maybe mdb_cursor_put() gets split in several functions, since much of the work in the recursive put()s will be unneeded.

1 0

(ITS#7771) liblmdb cursor issues
by h.b.furuseth＠usit.uio.no 22 Dec '13

22 Dec '13

Full_Name: Hallvard B Furuseth Version: mdb.master, 4c8f57615c5ca7b014c038e59c1045182e74f5ad OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-131222.c Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard mdb_cursor_put() doc bug in lmdb.h: "If the function fails for any reason, the state of the cursor will be unchanged." That's quite untrue. To do that, the function must backup the cursor before moving it. (What is a "failure" anyway - are MDB_KEYEXIST and MDB_NOTFOUND failures?) Cursor tracking issues with MDB_DUPSORT: Cursor tracking sometimes ignores xcursors referring to sub-pages, yet code which uses an xcursor does not always fix that first. The enclosed program has several crashes. I.e. lots more code needs something like if ((leaf->mn_flags & (F_DUPDATA|F_SUBDATA)) == F_DUPDATA) m2->mc_xcursor->mx_cursor.mc_pg[0] = NODEDATA(leaf); before using an xcursor. I tried that everywhere before using xcursors: That helped, but it was not enough. E.g. after mdb_cursor_del() calls mdb_node_shrink(), it tracks cursors in the same sub-page but not nearby sub-pages. Also the fix suggested above means readers do more work that writers did not. Maybe instead all code which modified a database, should fix or invalidate that DB's cursors before returning (even at failure).

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 22 Dec '13

22 Dec '13

I wrote: > still wondering if env_open needs to fail if F_NOCACHE fails. Oops - env_copy, not env_open. -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 22 Dec '13

22 Dec '13

This was fixed in LMDB 0.9.9, except: If both O_DIRECT and F_NOCACHE are #defined, both are used. Looks a bit strange. Maybe just one should be used in that case. (Which?) Also I'm still wondering if env_open needs to fail if F_NOCACHE fails. Anyway, maybe it should be something like this. The "else {}" is in case O_DIRECT is an unsupported dummy definiton: #ifdef O_DIRECT if ((rc = fcntl(newfd, F_GETFL)) != -1) (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); else #endif { #ifdef F_NOCACHE /* __APPLE__ */ (void) fcntl(newfd, F_NOCACHE, 1); #endif } -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 22 Dec '13

22 Dec '13

The remaining issues were fixed in LMDB 0.9.9. Closing this ITS. -- Hallvard

1 0

(ITS#7770) mdb_stat in cn=monitor
by michael＠stroeder.com 19 Dec '13

19 Dec '13

Full_Name: Version: OS: URL: Submission from: (NULL) (212.227.35.93) Feature request: It would be handy to have output of mdb_stat in cn=monitor.

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 19 Dec '13

19 Dec '13

--001a11c36ad2fcb4a204ede39c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/19 Christian Kratzer <ck(a)cksoft.de> > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > >> I sent it by mail but I think it is too big and queued. So here is all >> >> configuration and test result: >> >> http://pastebin.com/earKiHnH >> > > I have not worked trhough all your examples and configs yet as I am > travelling at the moment but things seem quite clear to me. > > > The password lock from you slaves never arrives on your master as you > have not configured referrals or any other kind of replication of state > from your slave to your master. > > That means the data on the masters and the slaves is inconsistent. > > As syncrepl as you use it always replaces the entire entry any changes > from the master will complelete overrite anything on the slaves. > > There is no merging of data in syncrepl. > If you take time to read all I sent, you will see that a first modification on the master DO NOT modifiy ppolicy attributes on the slave, the second modification do. Whatever you think, there is a bug here. If you read with caution the ppolicy draft, you will see that pwdAccountLockedTime and some other attributes SHOULD NOT be replicated on read-only replicas. > > This is working as designed and is not a bug by my understanding. > > We disagree a lot on this point. > You have at least following two options from what I see: > > 1. configure referrals and chaining so password locks etc... on the slav= e > get forwarded to the masters and replicated back to the slave. > > This means that you need to configure lcPPolicyForwardUpdates: TRUE > and chaining on your slave. > I tested it with success (almost, see ITS#7767 and ITS#7768) > > 2. configure multimaster replication so password locks get replicated > to your master. > > I did not test if the bug occurs in multimaster, but I think not. > You should close this ITS and we can discuss anything further on the > regular mailing lists. > > As said above, I am pretty sure there is a bug. Maybe an OpenLDAP developer should give its opinion on this ITS. Cl=E9ment. --001a11c36ad2fcb4a204ede39c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/19 Christian Kratzer <span dir=3D"ltr"><<a href=3D"mailt= o:ck@cksoft.de" target=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"im">Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> I sent it by mail but I think it is too big and queued. So here is all<div = class=3D"im"><br> configuration and test result:<br> <br> <a href=3D"http://pastebin.com/earKiHnH" target=3D"_blank">http://pastebin.= com/earKiHnH</a><br> </div></blockquote> <br> I have not worked trhough all your examples and configs yet as I am<br> travelling at the moment but things seem quite clear to me.<br></blockquote= ><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The password lock from you slaves never arrives on your master as you<br> have not configured referrals or any other kind of replication of state<br> from your slave to your master.<br> <br> That means the data on the masters and the slaves is inconsistent.<br> <br> As syncrepl as you use it always replaces the entire entry any changes<br> from the master will complelete overrite anything on the slaves.<br> <br> There is no merging of data in syncrepl.<br></blockquote><div><br><br><br><= /div><div>If you take time to read all I sent, you will see that a first mo= dification on the master DO NOT modifiy ppolicy attributes on the slave, th= e second modification do. Whatever you think, there is a bug here.<br> </div><div><br><br><br></div><div>If you read with caution the ppolicy draf= t, you will see that pwdAccountLockedTime and some other attributes SHOULD = NOT be replicated on read-only replicas.<br></div><div><br>=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br> This is working as designed and is not a bug by my understanding.<br> <br></blockquote><div><br><br></div><div>We disagree a lot on this point.<b= r><br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You have at least following two options from what I see:<br> <br> 1. =A0configure referrals and chaining so password locks etc... on the slav= e<br> =A0 =A0 get forwarded to the masters and replicated back to the slave.<br> <br> =A0 =A0 This means that you need to configure lcPPolicyForwardUpdates: TRUE= <br> =A0 =A0 and chaining on your slave.<br></blockquote><div><br><br></div><div= >I tested it with success (almost, see ITS#7767 and ITS#7768)<br></div><div= >=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <br> 2. =A0configure multimaster replication so password locks get replicated<br= > =A0 =A0 to your master.<br> <br></blockquote><div><br><br></div><div>I did not test if the bug occurs i= n multimaster, but I think not.<br><br>=A0<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> You should close this ITS and we can discuss anything further on the<br> regular mailing lists.<div class=3D"HOEnZb"><div class=3D"h5"><br></div></d= iv></blockquote><div><br><br><br><br></div><div>As said above, I am pretty = sure there is a bug. Maybe an OpenLDAP developer should give its opinion on= this ITS.<br> <br><br>Cl=E9ment.<br></div></div></div></div> --001a11c36ad2fcb4a204ede39c11--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 19 Dec '13

19 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1095844242-1387443188=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > I sent it by mail but I think it is too big and queued. So here is all > configuration and test result: > > http://pastebin.com/earKiHnH I have not worked trhough all your examples and configs yet as I am travelling at the moment but things seem quite clear to me. The password lock from you slaves never arrives on your master as you have not configured referrals or any other kind of replication of state from your slave to your master. That means the data on the masters and the slaves is inconsistent. As syncrepl as you use it always replaces the entire entry any changes from the master will complelete overrite anything on the slaves. There is no merging of data in syncrepl. This is working as designed and is not a bug by my understanding. You have at least following two options from what I see: 1. configure referrals and chaining so password locks etc... on the slave get forwarded to the masters and replicated back to the slave. This means that you need to configure lcPPolicyForwardUpdates: TRUE and chaining on your slave. 2. configure multimaster replication so password locks get replicated to your master. You should close this ITS and we can discuss anything further on the regular mailing lists. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1095844242-1387443188=:27797--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs