Full_Name: Lukas W Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2407:7000:9a07:8600::2)

The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is inconsistent with those of other OPs. For instance, MDB_NEXT does not change the cursor's position, as this was already done by mdb_cursor_del. As far as I understand, mdb_cursor_get can be expected to behave just like usual, whether mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra checks when e.g. removing particular items in a loop based on some criterion (as described and discussed in http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and follow-ups).

However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the following three items:

#1: "a" --> 1 #2: "b" --> 1 #3: 2b2b" --> 2

Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1 is removed and the cursor points to #2 (though this is not documented anywhere). We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is returned, making anyone who's unaware of this behaviour believe that there's another item with the key "a". In my particular case, this leads to #2 being deleted as well, even though I only expected to touch items with the key "a", which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place. In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del call, even though one would expect it not to jump across "key boundaries".

On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406 this would have resulted in an assertion failure.

You could classify this as a bug and adjust the behaviour to match MDB_NEXT's, or you could document the behaviour of mdb_cursor_del regarding the cursor's state. Either would be appreciated.