New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: lmdb support #46
Conversation
Not had a chance to review, but definite +1 in principle. |
Since I had to rebase this code to the trunk, I'm no longer able to run tests. If anyone can see where I'm missing linking the library, feel free to review the commit.
|
Add -llmdb to test/Makefile.in so test can be compiled without any error.
build.conf
Outdated
@@ -22,6 +22,7 @@ paths = | |||
crypto/crypt_blowfish.c | |||
dbm/apr_dbm_sdbm.c | |||
dbm/apr_dbm.c | |||
dbm/apr_dbm_lmdb.c |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed, the DBM drivers which can be built as DSOs should not be listed here otherwise it will get linked twice.
I've tested this with mod_dav and it seems to work well. As well as the changes described above I changed the |
- Remove lmdb driver from build.conf so it won't get linked twice! - Revert e147886
Thanks Joe for reviewing my changes. Previously, I was configurating the lmdb driver with:
And I was having troubles with loading lmdb driver as DSO. It was failing during DSO loading phase. I hope there is no issue with this and it is just some configuration thing. |
- Removed wrong lines from build.conf in ad34f18. Revering and removing correct line
if using MDB_NOSUBDIR per http://www.lmdb.tech/doc/group__mdb.html#ga32a193c6bf4d7d5c5d579e71f22e9340 Merging the change suggested by @notroj apache@26afe6b
a non-existent database.
(just like apr_status_t) map those values directly; map all other errors as APR_EGENERAL. APR-internal APIs should not use error codes within the APR_OS_START_USEERR number region (mistake common to dbm/*.c.)
overhead of per-transaction fdatasync() calls, bringing comparable behaviour/performance to BDB etc. Arguably this behaviour could be controlled by a new flag passed in the mode parameter of apr_dbm_open*.
Lmdb support
which was originally used for dynamic database resizing in case the database was full. This function is no longer used and the size of the database is set to UINT32_MAX in vt_lmdb_open() function.
Thanks a lot for the contribution, @uhliarik |
There is still WIP.