Re: limits on internal searches

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

> I've run into a problem with test017 which is currently failing for HEAD
> after I added some consistency checks on the values of search limits.
> I'm about to fix it, but I found out that some syncrepl code is checking
> search limits before running internal searches.  Is it intended?  I mean,
> is there any reason the identity that performs an internal search needs to
> check if any limits are set?  In that case, I strongly suggest any time
> limits
> are checked, an appropriate value is provided to fields op->ors_tlimit
> and op->ors_slimit.  By protocol, these fields can only have values >= 0,
> so if theey're set to SLAP_NO_LIMIT (= -1) it means they're being used
> in an internal search that requirs no limitations.  Otherwise, please set
> them to 0 (no specific limit required, incurring in soft limits if any)
> or to a positive value (e.g. 1 is used for auth{cz} related internal
> searches
> because strictly one value is required.

Yes, it is intended to apply the limits of the updatedn user.
The original intention was to apply the limit spec to the entire sync
operation consisting of multiple internal search operations. op->ors_slimit
is decremented by one each time the internal search in syncrepl_entry()
finds the entry having the matching entryUUID. The idea was to impose the
limit to a single sync operation in the consumer as it is in fact a single
search in the provider side. If the sizelimit in the implementation should
be only meaningful within a single internal search, we have the following
options : 1) set op->ors_slimit to 0 and call limits_check() to honor the
limit setting of updatedn in a single search; 2) set op->ors_slimit to 1 and
treat SIZELIMIT_EXCEEDED as an consistency error because entryUUID is
unique; or 3) just set op->ors_slimit to SLAP_NO_LIMIT. The current HEAD is
doing 1), but it is less meaningful to honor the limit setting per search
operation because the number of match is one at most.
- Jong-Hyuk