Re: back-mdb - futures...

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Hallvard B Furuseth writes:
> One big problem, if I understand you correctly, is that a database
> accumulates the results bugs more efficiently than anything else.
> There's no layer between slapd and the disk database which may catch
> an error or fail before the error gets saved.

More importantly, an Entry* from the database is a write handle into the
database which other modules *must not* make use of.  If they do, the
write happens even if the database never makes a decision to write
anything.  E.g. in a search operation if overlay rwm meddles a bit too
deeply.  Though that problem can be fixed with... sigh, an entry cache.

> So if something does a wild pointer write which ends up in the database,
> it stays written.  If something creates a wild pointer out from an entry
> in the database (ping ITS#5340), you've saved a "slapd will crash" state
> into the database itself.  be_release() of the entry doesn't help, nor
> does stopping slapd.  slapcat/slapadd might save you since it doesn't
> need the entire database, but it too is more fragile.

-- 
Hallvard