So it means the following: with the current code, when the client code wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not depend on the number of records.
IMHO, the current behavior is a bit cumbersome. Would it be that complex to update the client code? Claude On Sun, 14 Apr 2013 23:56:41 GMT [email protected] wrote: > [email protected] wrote: > > [email protected] wrote: > >> Full_Name: Claude Brisson > >> Version: HEAD > >> OS: linux 64 > >> URL: > >> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULTIPLE.patch > >> Submission from: (NULL) (84.103.74.130) > >> > >> > >> In a db with MDB_DUPSORT flag, when there is only one DUP data for > >> a key, F_DUPDATA is not set for this key, and there is no > >> sub-cursor. > >> > >> In this case, the current behaviour of MDB_GET_MULTIPLE and > >> MDB_NEXT_MULTIPLE is broken because they make the assumption that > >> there is always a sub-cursor for DUP data, which is only true for > >> keys with more than one DUP data. > >> > >> This patch address this specific issue. > > > > Something's wrong with this patch, it breaks > > MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate > > further. > > > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only > valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is > essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If > there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return > MDB_NOTFOUND. > > This patch was in mdb.master but has now been reverted. Closing this > ITS. >
