...

...

I have a new repro of an ITS#8264-like situation, but with different input data and with slightly different results. Note that ITS#8264 was fixed with the dataset provided in that bug; this is a different dataset and produces different results.

The referenced test runs twice: once with mdb_cursor_del and once with

mdb_del.

...

...

Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the database. In this case, mdb_del incorrectly removes one extra key (a key prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place that should have been deleted (those keys begin with 05000000000000003a...). This last item is the primary difference between these two bugs.

Unlike ITS#8264, you do not need to remove the database in between test runs in order to repro this issue, although the results are still incorrect and will eventually cause a bus error.

Thanks again for the excellent bug reports. Fixed now in git.

=20 I should also note that this is not a sensible use case. mdb_del has to construct a cursor to perform its work; if you already have a cursor open=

you

should just use mdb_cursor_del. mdb_del is meant for one-shot use and is much slower than mdb_cursor_del when used in an iteration.

Thanks for this information. I will make the change to use mdb_cursor_del = when possible. There are a couple of circumstances where I do not currentl= y have access to the cursor though and will need to use mdb_del (or mdb_put= , for updates) inside of the cursor. I will look into passing the cursor u= p to my higher-level API callers though...

Note that I just reported ITS#8300, which was found after making the switch= to mdb_cursor_del (and after applying the fix for ITS#8299).

Thanks, Michael Alyn Miller