Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour

[claude.brisson@gmail.com]

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
hyc@symas.com wrote:

> hyc@symas.com wrote:
> > claude.brisson@gmail.com 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.
>