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