openldap-bugs May 2026

openldap-bugs@openldap.org

1 participants
100 discussions

[Issue 10509] New: 2.7: Feature notes for announcement file
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10509 Issue ID: 10509 Summary: 2.7: Feature notes for announcement file Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add feature notes for the 2.7 announcement file -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 22 Jul '26

22 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) 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: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 30

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 21 Jul '26

21 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 9667] New: 2.6 to 2.7 upgrade documentation
by openldap-its＠openldap.org 21 Jul '26

21 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=9667 Issue ID: 9667 Summary: 2.6 to 2.7 upgrade documentation Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to document any upgrade information for going from 2.6 to 2.7 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 20 Jul '26

20 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Created attachment 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10490] New: Bump library minor version(s)
by openldap-its＠openldap.org 14 Jul '26

14 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10490 Issue ID: 10490 Summary: Bump library minor version(s) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Tracking bug for 2.7 branchpoint if we expose new interfaces in either library. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10054] New: Value size limited to 2,147,479,552 bytes
by openldap-its＠openldap.org 12 Jul '26

12 Jul '26

https://bugs.openldap.org/show_bug.cgi?id=10054 Issue ID: 10054 Summary: Value size limited to 2,147,479,552 bytes Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: louis(a)meilisearch.com Target Milestone: --- Hello, According to the documentation[0], a database that is not using `MDB_DUPSORT` can store values up to `0xffffffff` bytes (around 4GB). In practice, under Linux, the actual limit is `0x7ffff000` though (2^31 - 4096, so around 2GB). This is due to the write loop in `mdb_page_flush`. The `wsize` value determining how many bytes will be written can be as big as `4096*dp->mp_pages`[1], and the number of overflow pages grows with the size of the value put inside the DB. The `wsize` is not split in smaller chunks in the case where there are many overflow pages to write, and as a result the call to `pwrite`[2] does not perform a full write, but only a "short" write of 2147479552 bytes (the maximum allowed on a call to `pwrite` on Linux[3]). This would be OK if the short write condition was handled by looping and performing another `pwrite` with the rest of the data, but instead `EIO` is returned[4]. There seems to be a related, but different issue on macOS when trying to `pwrite` more the 2^31 bytes, that was already reported[5]. This issue was reported to me by a Meilisearch user because it causes their database indexing to fail[6]. I had to investigate a bit because their setup was peculiar (high number of documents in their database) and the `EIO` error code is not very descriptive of the underlying issue. I join a C reproducer of the issue that attempts to add a 2147479553 bytes value to the DB and fails with `EIO` (decreasing `nb_items` to a smaller value such as `2107479552` does succeed)[7]. Thank you for making LMDB! Louis Dureuil. [0]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/lmdb.h#LL284… [1]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#LL3770… [2]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3820 [3]: https://stackoverflow.com/questions/70368651/why-cant-linux-write-more-than… [4]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3840 [5]: https://bugs.openldap.org/show_bug.cgi?id=9736 [6]: https://github.com/meilisearch/meilisearch/issues/3654 [7]: https://github.com/dureuill/lmdb_3654/tree/main -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9223] New: Add support for incremental backup
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9223 Bug ID: 9223 Summary: Add support for incremental backup Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For LMDB 1.0, add support for incremental backups -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Issue 9496] New: Some writes missing from database
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9496 Issue ID: 9496 Summary: Some writes missing from database Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- With the attached test program, some of my database writes appear not to actually be written to the database. For example, a run may look like this: $ ./run.sh All done. All finished 1802 test.txt foo_200 is missing bar_200 is missing foo_404 is missing bar_404 is missing foo_407 is missing bar_407 is missing The script that I am using to run the program is below. This is using mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4 filesystem. Is this an LMDB bug, or is there a bug in my code? Thanks Ian #!/bin/sh set -e if ! [ -d lmdb ] then rm -rf lmdb git clone https://github.com/LMDB/lmdb.git INSTALL_DIR="`pwd`/inst" cd lmdb/libraries/liblmdb make install prefix="$INSTALL_DIR" cd ../../.. fi gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread rm -f test.db test.db-lock ./loop echo "All finished" mdb_dump -np test.db > test.txt wc -l test.txt for i in `seq 100 999` do if ! grep -q "foo_$i" test.txt then echo "foo_$i is missing" fi if ! grep -q "bar_$i" test.txt then echo "bar_$i is missing" fi done -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9619] New: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file
by openldap-its＠openldap.org 30 Jun '26

30 Jun '26

https://bugs.openldap.org/show_bug.cgi?id=9619 Issue ID: 9619 Summary: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file Product: LMDB Version: 0.9.29 Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- When copying an LMDB database with mdb_env_copy2 with the MDB_CP_COMPACT with mdb.master3, the resulting mdb file seems to be corrupt and when using it in LMDB, I get segmentation faults. Copying without the compacting flag seems to work fine. I apologize, I know this is not a very good issue report, as I haven't had a chance to actually narrow this down to a more reproducible/isolated case, or look for how to patch. I thought I would report in case there are any ideas on what could cause this. The segmentation faults always seem to be memory write faults (as opposed to try fault on trying to read). Or perhaps the current backup/copying functionality is eventually going to be replaced by incremental backup/copying anyway (https://twitter.com/hyc_symas/status/1315651814096875520). I'll try to update this if I get a chance to investigate more, but otherwise feel free to ignore/consider low-priority since the work around is easy. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2026