[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-bdb flaw

Hallvard B Furuseth wrote:
Howard Chu writes:
Hallvard B Furuseth wrote: 
Is the problem only to (make it feasible to) detect this situation, or
also to act on it?  To detect it, I assume Delete before returning
notAllowedOnNonLeaf could search with scope onelevel/children, and see
if it finds any entires.

Yes... back-bdb would also need to check this for modrdn as well.  Seems
like quite a lot of extra expense to perform this check each time.

Only at failure.

We need to do this check whenever deleting an entry whose parent's onelevel index is an IDL range.

Maybe it's more work than I imagine - it's an index after all.

Yes, it's an index. But there's no efficient way to determine this info without the index. (Which again is why back-hdb doesn't do things this way...) The checks we're considering here could also seriously impair concurrency, since the Delete transaction could end up taking read locks on many entries before finding the next sibling.

But IIRC we already have similar slowdowns in situations I'd
assume are more common.  When deleting multiple attribute values in an
entry have the same hash, or something.

No, not a comparable situation. In that case, we compute all of the hashes in memory but we cancel out the duplicates and only push the true changes into the DB. Computing the hashes is cheap, DB operations are not.

Seems like it's time to revisit this thread...
http://www.openldap.org/lists/openldap-devel/200503/msg00012.html

The notion of bit-vectors for IDLs is looking good again. The whole reason this problem exists is because range IDLs lose so much information.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/