RE: (ITS#3824) slapadd/slapindex -q can break db_stat

[mhardin@symas.com]

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org [mailto:owner-openldap-
> bugs@OpenLDAP.org] On Behalf Of dbroady1@yahoo.com
[...]
> Would it be possible to change the compilation-conditional code to a
> runtime
> conditional check using db_version(), to avoid performing the environment
> destroy with a 4.3 library?

Yes, that would be possible, but if it's a choice between conditional
compilation and a runtime check, I'd choose conditional compilation because
it's a lot simpler. The main reason I can think of that a runtime check
would make sense is if I were compiling with one version of the db lib and
actually running with a later version. I can't see people doing that with
the db-4.2 and db-4.3 libraries.

Keep in mind, slapadd -q turns off logs and transactions, so its use is
somewhat risky. If the system should crash during slapadd or if slapadd
experienced a segv, the database will be left in an inconsistent state and
is very likely to be unusable. In fact, the back-bdb startup code will not
allow a database that has experienced this sort of event to be used, and
db_recover will not be able to recover from that. For this reason, the -q
option will mostly be used with complete reloads, not to perform offline
updates of production databases. I don't think that the contents of the
cache (the only part of the environment that is useful after a run with the
-q flag enabled) are very useful, as they are not likely to be in there
because of a recent search. Thus, the cost of removing the cache after a run
with -q is small.

Cheers,

Matthew Hardin
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
http://www.symas.com