openldap-bugs

openldap-bugs@openldap.org

1 participants
21198 discussions

[Issue 10395] New: Support multiple readers on uncommitted changes
by openldap-its＠openldap.org 03 Apr '26

03 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10395 Issue ID: 10395 Summary: Support multiple readers on uncommitted changes Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Created attachment 1086 --> https://bugs.openldap.org/attachment.cgi?id=1086&action=edit A patch to support multiple readers on uncommitted changes Hello, The attached patch is not meant to be merged immediately into LMDB. Still, it demonstrates how I added a helpful feature to the key-value store: reading uncommitted changes from multiple transactions. I am conscious that the patch still requires some work and uses non-C99 features, i.e., atomics are C11, which could be a blocker for it to be merged upstream. I would also be delighted to merge these changes under a flag/define to ensure we don't impact other users with non-C99 stuff. The main feature we need at Meilisearch is to read uncommitted changes from multiple threads, compute parallel post-processing of different data structures [1], and speed up the search requests. We could have done the post-processing in a following transaction by opening multiple read transactions, but this would mean that the post-processed data structure would not include newly inserted or modified document IDs. Both data structures would be desync. Regarding the design choice, I decided to follow the same design as the nested write transactions: use the parent argument of the mdb_txn_begin [2], and allow the MDB_RDONLY flag, which was disallowed when the parent argument was non-NULL [3]. I find it clear enough that, by calling the mdb_txn_begin function with these arguments, you can call it multiple times (I need to update the doc) to obtain nested read-only transactions from the parent write transaction. ret = mdb_txn_begin(env, parent_txn, MDB_RDONLY, new_nested_rtxn); Note that this early proposal lacks security and error handling. The generated transactions are fake-read-only and actually write transactions that share the underlying parent allocations and data structures. This is unsafe and must be changed or reviewed carefully, but most importantly, we need to add read-only capabilities to these transactions to disallow writes. Using a Rust wrapper on top of LMDB, I wrapped the fake read-only transactions into ReadTxn, which disallows any writes at compile time. However, I haven't checked the conflict database creations or openings. The main issues I encountered were concurrent free of the main shared data structures when the different threads owning the transactions were dropping the transactions simultaneously. So, I decided to implement the equivalent of an ARC to free resources only when the last nested transaction was freed. I can share numbers about how this feature improves the post-processing by 4x-9x or from 1200s to 120s [1]. You can look at this PR, which I would be happy to merge once an improved version of this patch lands on LMDB upstream. I would be very happy if you could guide me a bit on how I could improve this patch to make it mergeable into LMDB. We want to contribute useful features like this to LMDB and not keep a deviant fork. LMDB works great; we are happy about it, and its performance is predictable. Have a lovely week, kero [1]: https://github.com/meilisearch/meilisearch/pull/5307 [2]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… [3]: https://github.com/LMDB/lmdb/blob/14d6629bc8a9fe40d8a6bee1bf71c45afe7576b6/… -- You are receiving this mail because: You are on the CC list for the issue.

1 28

[Issue 10485] New: potential division by zero in tier bestof
by openldap-its＠openldap.org 02 Apr '26

02 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10485 Issue ID: 10485 Summary: potential division by zero in tier bestof Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In rare cases gettimeofday could fall on tv_usec == 0 so we will just accept it's been exactly 1 second and go with that. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10484] New: lloadd operations_timeout/connection_timeout type confusion
by openldap-its＠openldap.org 02 Apr '26

02 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10484 Issue ID: 10484 Summary: lloadd operations_timeout/connection_timeout type confusion Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- connection_timeout reads unrelated stack memory passed in *arg (operations_timeout passed a time_t which is shorter than struct timeval). Fix is coming -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10483] New: slapo-chain leaks structures added online
by openldap-its＠openldap.org 01 Apr '26

01 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10483 Issue ID: 10483 Summary: slapo-chain leaks structures added online Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- chain_ldadd stores the DB in ce->ce_be, but there is no teardown of these on shutdown so they get leaked and no way for ldap_chain_db_destroy to reach them either. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10482] New: Accesslog leaks UUID buffer when operation not logged
by openldap-its＠openldap.org 01 Apr '26

01 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10482 Issue ID: 10482 Summary: Accesslog leaks UUID buffer when operation not logged Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Fix incoming -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10481] New: cn=config leaks data in error path
by openldap-its＠openldap.org 01 Apr '26

01 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10481 Issue ID: 10481 Summary: cn=config leaks data in error path Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Attempting an Add when objectclass is not known leaks in-progress structures. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10480] New: Use after free in cn=config replication
by openldap-its＠openldap.org 01 Apr '26

01 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10480 Issue ID: 10480 Summary: Use after free in cn=config replication Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a renumber needs to happen, cn=config frees e->e_name, but some code (e.g. syncrepl) sets op->o_req_dn to point to the same and as such it can't be used anymore. This causes a crash in syncrepl (if LDAP_DEBUG_SYNC is on) and accesslog during cn=config replication. Either syncrepl (and others) shouldn't do this or cn=config should check for this case and adjust o_req_dn after the fact. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10479] New: syncprov doesn't cleanup abandoned psearch
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10479 Issue ID: 10479 Summary: syncprov doesn't cleanup abandoned psearch Product: OpenLDAP Version: 2.6.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In some cases, revealed in regression test for its#9338, abandoning a psearch doesn't cleanup the search operation. It remains on the connection's c_ops queue indefinitely. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10475] slapo-constraint URI mode fails to escape assertion values in internal catalog filters, enabling wildcard/filter-metachar allowlist bypass
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

1 0

[Issue 10476] slapo-pcache crashes on cached bind attributes containing LDAP filter metachars
by openldap-its＠openldap.org 31 Mar '26

31 Mar '26

https://bugs.openldap.org/show_bug.cgi?id=10476 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs