https://bugs.openldap.org/show_bug.cgi?id=8803
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Severity|normal |enhancement
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
Added to mdb.master3 in 7a1f36d51a27a8b638e470551cff99302cfa5048
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8250
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8250
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #5 from Howard Chu <hyc(a)openldap.org> ---
Added to mdb.master3 4cd8e451679511c8fbeff68f8a97cbe7b1268b48
Please test.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8361
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9208
Bug ID: 9208
Summary: LMDB feature request: variant of mdb_env_copy{,fd2}
that takes transaction as parameter
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: github(a)nicwatson.org
Target Milestone: ---
The mdb_env_copy* functions create a read transaction themselves to run the
backup on. New variants of these functions (one for mdb_env_copy2 and one for
mdb_env_copyfd2) would have a transaction parameter. This transaction would be
used instead of creating a new transaction.
Application code could use these new functions to synchronize consistent live
backups across multiple LMDB instances (potentially across multiple hosts).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8361
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
Unix case is a non-issue. libc only does the `sprintf(buf, "Error %d", err)`
fallback for error codes it doesn't recognize. These only occur when an old
libc is running on a newer kernel version (that happens to define new errno
values).
So in practice it only happens with extremely old statically linked binaries
running on a much newer system.
The Windows situation is a bit cleaner now that we're not using as many libc
error codes. (ITS#8192). In most cases none of that will matter. Also most
error messages are short, generally shorter than one 80 column line. Not worth
worrying about.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8192
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
In mdb.master3 bf5c4e0f2302c07a1a5552143be5a353a1fb3fe9
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8475
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10034
Issue ID: 10034
Summary: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: 763280032(a)qq.com
Target Milestone: ---
We found that when lmdb is opened after OS startup and data is written to it,
lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger
once);
We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)'
failed in mdb_page_search_root()); we want to know if there is a problem with
our usage;
Please Help Us
(gdb) x/8s 0x8baee988
0x8baee988: "8\373Ô²\b\371Ô²mdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in
mdb_page_search_root()"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8813
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FEEDBACK
--- Comment #7 from Howard Chu <hyc(a)openldap.org> ---
(In reply to markus(a)greenrobot.de from comment #5)
> On 24.10.19 03:49, Howard Chu wrote:
> > You're free to define MDB_TRPAGE_MAX to a larger value. It just means
> > you increase the chance of overrunning the 2GB available address space.
> > There's no magic, you can't fit every 64bit database workload into only
> > a 32bit address space. When your transactions are too large, the normal
> > thing to do is commit more often so they don't grow so large.
>
> I think you meant MDB_TRPAGE_SIZE? At least that seemed to work, while
> MDB_TRPAGE_MAX ended up in another MDB_TXN_FULL (tl[0].mid <
> MDB_TRPAGE_SIZE check failed).
>
> Doubling MDB_TRPAGE_SIZE also doubled the threshold of the object count
> where it starts failing: using 8192 it was able to remove 4M entries
> while the limit with 4096 was 2M entries.
>
> MDB_TRPAGE_SIZE is only used to malloc txn->mt_rpages (and some checks),
> as far as I can tell.
>
> To make a reasonable decision here, could you please confirm:
>
> 1. txn->mt_rpages is RAM only and has no impact on mmaped sections
> (and/or file format).
>
> 2. RAM consumption is defined by number of transactions only: per
> transaction MDB_TRPAGE_SIZE bytes is allocated. Other than that it does
> not increase memory consumption.
>
> 3. There is no other disadvantage other than higher memory consumption
> per transaction as written in the previous point.
>
>
> In that case, I think I'll go with 16K (or even 32K). Does not seem too
> much for an transaction, given that it quadruples the amount of data
> allowed to be processed. 32 bit devices are not servers, so I do not
> expect a high number of concurrent transactions anyway.
>
> Thanks!
>
> Markus
Sorry for going quiet. Yes, to all 3 of your points, it only affects in-memory
bookkeeping and has no effect on the file. The only consequence of increasing
these constants is potentially higher memory consumption.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8579
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Target Milestone|--- |1.0.0
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
I see no reason not to do this.
Some of the caveats about fork/exec are still overstated.
LMDB uses fcntl() locks, not flock(), so some of the concerns about flock()
semantics are irrelevant.
There is nothing useful an exec'd process can do with the me_fd, so yes, let's
close it.
Fixed in mdb.master3 cf52db2bee52796bb4140b32679f4723a0d7d44f
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8691
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
Unable to reproduce this any more. "--without-threads" is no longer a supported
configuration.
OpenLDAP 2.6 has no trouble starting/stopping on Windows.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6198
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10497
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8537
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WORKSFORME
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Howard Chu <hyc(a)openldap.org> ---
Didn't see any crash in current mdb.master3,
9aa3ac00567db8d5222abea46325a8b882937350
I see EINVAL on case 9 with the test program, trying to use MDB_GET_CURRENT
after and MDB_SET_KEY that returned MDB_NOTFOUND. This appears to be correct
behavior, since the cursor isn't pointing at anything when MDB_NOTFOUND is
returned.
On the reported commit ID, the test program asserts on case 0, but that doesn't
appear to be relevant any more.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9011
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
Why does a wrapper or binding care whether a txn is read-only or read-write?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8275
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
I don't see why this is necessary or useful. The caller supplied the name in
the first place, why do they need to ask for it back?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8502
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
(In reply to Hallvard Furuseth from comment #0)
> Full_Name: Hallvard B Furuseth
> Version: mdb.master, 26e226b2a8cdba4208eabca394537900c4eda3b3
> OS:
> URL:
> Submission from: (NULL) (81.191.45.31)
> Submitted by: hallvard
>
>
> mdb_cursor_count() has code to return MDB_NOTFOUND if !mc_snum,
> but it comes after if (! ... C_INITIALIZED) return EINVAL.
It sounds like the NOTFOUND test should just be deleted then, because
it's always unreachable.
When a DB is emptied, all cursors on it are de-initialized since there is
nothing for the cursors to point to. In an uninitialized cursor, none of the
other state is meaningful, so mc->mc_snum is irrelevant.
Changing the order of the tests would mean you get MDB_NOTFOUND even on a
cursor on a non-empty DB, if it has never been used yet. Is that actually a
more sensible result in that case?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8455
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
*** This issue has been marked as a duplicate of issue 8209 ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8209
--- Comment #10 from Howard Chu <hyc(a)openldap.org> ---
*** Issue 8455 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8590
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Summary|LMDB: Suppress SIGPIPE in |LMDB: Suppress SIGPIPE in
|mdb_env_copythr on OS X |mdb_env_copythr on OS X
Resolution|--- |TEST
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
Committed to git mdb.master / mdb.RE/0.9 / mdb.master3
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9099
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |SUSPENDED
Status|UNCONFIRMED |RESOLVED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9027
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9475
--- Comment #5 from Howard Chu <hyc(a)openldap.org> ---
In mdb.master3 63698faf2c159136443e5e3c07541201fca5ee71
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9475
Issue ID: 9475
Summary: Add support for MAP_POPULATE
Product: LMDB
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: aa531811820(a)gmail.com
Target Milestone: ---
In some case (such as cloud computing platforms), the reading speed of large
files is very fast while the small files is very slow, and we have enough
memory, so we hope to prefetch the entire LMDB file into the memory during MMAP
through the MAP_POPULATE flag . According to our test, this is faster than
using readahead flag. Here are some test data:
# mmap with no readahead
read one sample: 0.2s
total time: 4800s
# mmap with readahead
read one sample: 0.0001s~0.03s
total time: 95.86s
# mmap with MAP_POPULATE
db init: 20s
read one sample: 0.0001s
total time: 78s
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8684
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
Users are expected to adjust defines as necessary for their platform and
usecase.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8324
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9539
--
You are receiving this mail because:
You are on the CC list for the issue.