[Date Prev][Date Next]
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.