DB backend support for lmdb?

[Matthias Andree]

Am 17.07.2018 um 09:01 schrieb Matthias Andree:
> Am 17.07.2018 um 01:35 schrieb Steffen Nurpmeso:
>> Ahoi!  And HA!!
>>
>> Steffen Nurpmeso wrote in <20180716221310.qDo5g%steffen at sdaoden.eu>:
>>  |Steffen Nurpmeso wrote in <20180715001400.pHS5O%steffen at sdaoden.eu>:
>>  ||Matthias Andree wrote in <d38d0bd4-eb6e-6b0e-6252-6bf5223818f5 at an3e.de>:
>>  |||Am 21.06.2018 um 16:14 schrieb Steffen Nurpmeso:
>>  |||> Steffen Nurpmeso wrote in <20180529185111.0IjYp%steffen at sdaoden.eu>:
>>  |||>|Matthias Andree <matthias at an3e.de> wrote:
>>  |||>||Am 28.05.2018 um 23:57 schrieb Steffen Nurpmeso:
>>  |||>  ...
>>  ||Sorry for the long delay, this Thursday finally i have found time,
>>  | ...
>>  ||causes some tests to fail.  It is too late now, i have to go, and
>>  ||revisit that on Monday.
>>  ...
>>  |So i post what i have, it is what i thought would be final.
>>  |I thought only, because we have five failing tests still.
>>
>> This has not changed.  I will try on a GlibC and on FreeBSD
>> tomorrow.
> Hi Steffen,
>
> thanks for your contributions. I have tried on a plain Fedora 28 with
> glibc, and also see five failed tests,
>
> FAIL: t.encoding
> FAIL: t.nonascii.replace
> FAIL: t.maint
> FAIL: t.regtest
> FAIL: t.upgrade.subnet.prefix
>
> Especially since the system tests already PASS, it seems we need to hunt
> down a few borderline cases. I am using LMDB 0.9.22 for convenience.

Hi Steffen,

A bit of analysis on, for instance, t.nonascii.replace, reveals that one
borderline case causing several of the failures shown above is that
.WORDLIST_VERSION shows up with the LMDB driver where it does not show
with the default BerkeleyDB or KyotoCabinet DB backends.
I don't currently see why that is, and I am seriously wondering if the
other drivers are correct... currently it's just correct by majority
vote O:-)

I am running with -Dvvvvxd to see the ds_read/ds_write calls.

OTOH, I have identified the cause for bogofilter writing the
.WORDLIST_VERSION and .ENCODING tokens in read-only databases.
This has been fixed on the trunk, and I have synched the lmdb-support
branch with those trunk changes.
I have removed your workaround, and the self-test situation remains the
same, with the same five failures for the LMDB branch, without
introducing regressions for the KC, DB, SQLITE3 drivers.

Before doing further development, please switch to
^/branches/lmdb-support and/or update. I'm heading for bed now that
r7064 has been committed.

HTH a bit.

Regards,
Matthias