Re: back-mdb - futures...
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