openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#8124) Patch "Context for compare functions"
by hyc＠symas.com 03 May '15

03 May '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: LMDB mdb.master > OS: N/A > URL: https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… > Submission from: (NULL) (70.81.32.80) > > > New feature inclusion request: "Context for compare functions" > > I am finishing up a new perl module which is a very thin wrapper for LMDB. > (The current perl LMDB module does not fit my needs as it does not support > NO_TLS really support). > > When looking at mdb_set_compare and mdb_set_dupsort. > > There were three choices. > > * Not support mdb_set_compare, mdb_set_dupsort in the module. > * Capture each mdb_*(del|put|get) function to figure which dbi I am using. > * Add support for contexts in the compare functions. > > So I decided on the latter. > > I understand that passing a context for each compare can add some overhead. > So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is > enabled. I don't see supporting compare functions in interpreted languages being a realistic/worthwhile thing to do. The difference in performance is orders of magnitude. I also don't believe such conditional compilation is a good idea. LMDB is designed to be simple, to have very few options, and to Just Work the same on every platform. Conditionally compiled features are horrible because you can't guess which features will be present in a system-installed library. -- -- 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#8124) Patch "Context for compare functions"
by rouzier＠gmail.com 02 May '15

02 May '15

Full_Name: James Rouzier Version: LMDB mdb.master OS: N/A URL: https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… Submission from: (NULL) (70.81.32.80) New feature inclusion request: "Context for compare functions" I am finishing up a new perl module which is a very thin wrapper for LMDB. (The current perl LMDB module does not fit my needs as it does not support NO_TLS really support). When looking at mdb_set_compare and mdb_set_dupsort. There were three choices. * Not support mdb_set_compare, mdb_set_dupsort in the module. * Capture each mdb_*(del|put|get) function to figure which dbi I am using. * Add support for contexts in the compare functions. So I decided on the latter. I understand that passing a context for each compare can add some overhead. So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is enabled. This patch does the following. * Adds context to the MDB_cmp_func typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b ,void* ctx); * And two new data members to the MDB_dbx struct * void *md_cmpctx; /**< user-provided context for md_cmp */ * void *md_dcmpctx; /**< user-provided context for md_dcmp */ * Add functions for setting/getting the contexts * int mdb_set_cmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_set_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_get_cmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); * int mdb_get_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); I have no problem maintaining this as a separate patch if it does not fit in the vision of LMDB. I believe this can be useful for people who wants to add LMDB to a scripting language. New feature inclusion request: "Context for compare functions" I am finishing up a new perl module which is a very thin wrapper for LMDB. (The current perl LMDB module does not fit my needs as it does not support NO_TLS really well). When looking at mdb_set_compare and mdb_set_dupsort. There were three choices. * Not support mdb_set_compare, mdb_set_dupsort in the module. * Capture each mdb_*(del|put|get) function to figure which dbi I am using. * Add support for contexts in the compare functions. So I decided on the latter. I understand that passing a context for each compare can add some overhead. So I made this feature optional it is only enabled if the macro MDB_CMP_CTX is enabled. This patch does the following. * Adds context to the MDB_cmp_func typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b ,void* ctx); * And two new data members to the MDB_dbx struct * void *md_cmpctx; /**< user-provided context for md_cmp */ * void *md_dcmpctx; /**< user-provided context for md_dcmp */ * Add functions for setting/getting the contexts * int mdb_set_cmpctx(MDB_txn *txn, MDB_dbi dbi, void *ctx); * int mdb_set_dcmpctx(MDB_txn *txn, MDdbi i dbi, void *ctx); * int mdb_get_cmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); * int mdb_get_dcmpctx(MDB_txn *txn, MDB_dbi dbi, void **ctx); I have no problem maintaining this as a separate patch if it does not fit in the vision of LMDB. I figured it might be very useful for others. Thank You for creating and releasing LMDB I, James Rouzier, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by h.b.furuseth＠usit.uio.no 01 May '15

01 May '15

test001 still crashes if you insert assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int)); in mdb_cmp_int(). Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...". I don't see "same size" in the INTEGERDUP doc, it's looser than for INTEGERKEY integers. Or have I gone blind again? Anyway, it would be clearer to cut some doc and say data behave like INTEGERKEY keys. Ignoring that, though: Looking yet again at the doc, mdb_dbi_open():INTEGERKEY says "typically" sizeof(int/size_t), I can't see it requires these sizes. Maybe you copied that from a suggestion from me back when I asked for clarifications. "keys must all be of the same size" in the doc is unclear. I gather it should be "... in the DB's lifetime". But it can be read as "...at a given time": Write size_t-sized integers, empty the DB, then write int-sized integers. That does not work, since me_dbxs[].md_dcmp is updated. "mc->mc_dbx->md_dcmp = mdb_cmp_clong;" looks wrong. That updates env->me_dbxs[], I believe. But: If we mdb_txn_abort(), the txn has not been a no-op: It will require next txn and even existing txns to use size_t-sized INTEGERDUP data. The assignment may be non-atomic. Another txn may be reading the pointer. I expect IL32P64 architectures are examples, and also function pointers can be quite large. (OpenLDAP expects void*-sized function pointers though.)

1 0

Re: (ITS#8123) Incorrect loglevel man page content
by hyc＠symas.com 01 May '15

01 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.12.43.27) > > > The slapd-config man page contains a slightly incorrect explaination for the > olcLogLevel config element. One can read : > > olcLogLevel: <integer> [...] > ... > The desired log level can be input as ... or as a list of the names that > are shown between brackets... > > but the sample does not show any bracket being used : > > olcLogLevel: acl trace > > Actually, using brackets does not work (you can't inject the attribute using > [acl trace] or {acl trace}) "between brackets" refers to the manpage text itself, it does not mean to enter anything with literal brackets. It probably should be corrected to "between parentheses" since it is referring to e.g. 1 (0x1 trace) trace function calls -- -- 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

Re: (ITS#8122) Incorrect Schema content
by hyc＠symas.com 01 May '15

01 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: Mac OSX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.12.55.37) > > > There are a few elements in some schema which are incorrect (even if it does not > break anything) : This is a known issue. Will not be fixed. > > Core schema > ----------- > * The organizationalRole OC has the preferredDeliveryMethod AT declared twice > * The residentialPerson OC has the preferredDeliveryMethod AT declared twice These definitions are copied verbatim from RFC2256. We do not alter published schema from their published form. > Cosine schema > ------------- > * The domain OC has the streetAddress AT declared twice > * The RFC822localPart OC has the telephoneNumber AT declared twice Again, copied verbatim from RFC1274. -- -- 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#8123) Incorrect loglevel man page content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.43.27) The slapd-config man page contains a slightly incorrect explaination for the olcLogLevel config element. One can read : olcLogLevel: <integer> [...] ... The desired log level can be input as ... or as a list of the names that are shown between brackets... but the sample does not show any bracket being used : olcLogLevel: acl trace Actually, using brackets does not work (you can't inject the attribute using [acl trace] or {acl trace})

1 0

(ITS#8122) Incorrect Schema content
by elecharny＠apache.org 01 May '15

01 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: Mac OSX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.12.55.37) There are a few elements in some schema which are incorrect (even if it does not break anything) : Core schema ----------- * The organizationalRole OC has the preferredDeliveryMethod AT declared twice * The residentialPerson OC has the preferredDeliveryMethod AT declared twice Cosine schema ------------- * The domain OC has the streetAddress AT declared twice * The RFC822localPart OC has the telephoneNumber AT declared twice

1 0

(ITS#8121) mention LDAP_SASL_SIMPLE in ldap_bind.3
by ryan＠openldap.org 30 Apr '15

30 Apr '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In IRC, txtd noted that both ldap_simple_bind and ldap_bind are marked as deprecated in ldap.h, and asked about the recommended way to perform a simple bind. OpenLDAP code uses ldap_sasl_bind(LDAP_SASL_SIMPLE), but that flag is not mentioned in any man page.

1 0

(ITS#8120) CHECK_CSN unreliable as final check is after mutex is unlocked
by quanah＠openldap.org 30 Apr '15

30 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The CHECK_CSN ifdef code is unreliable as the final check on the CSN's is done after the mutex is unlocked, while all of the other checks are done after the mutex is locked. This can cause the assert to trigger on valid CSNs.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by hyc＠symas.com 30 Apr '15

30 Apr '15

Leonid Yuriev wrote: > 29.04.2015 21:55, Howard Chu пишет: >> Leonid Yuriev wrote: >> >>> But what about 5-bytes keys from indexer? >>> - How ones should be compared, as a 4-byte int without MSB, or as a >>> padded 8-byte long? >> >> The indexer doesn't use MDB_INTEGER so your question is irrelevant. >> > OK, but then - what is the purpose of MDB_INTEGERDUP in > mdb_attr_dbs_open()? > > flags = MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP; > if ( !(slapMode & SLAP_TOOL_READONLY) ) > flags |= MDB_CREATE; > > Think it is not necessary, is it? You really think so? Have you thought about what the actual *values* are in an index, instead of just the keys? Anyway, this ITS is resolved. Thank you for reporting the bug. If you want to ask further questions about how the indexer works take it to openldap-devel. -- -- 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

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