Re: limits on internal searches

["Pierangelo Masarati" <ando@sys-net.it>]

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

So we'd rather use (2), right?

also, current HEAD was doing (1) in syncrepl_del_nonpresent(), but it was
leaving the ors_{st}limit unset in syncrepl_entry(); I applied (1) there
as well.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497