RE: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)

[malyn@strangegizmo.com]

> >> 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