[Date Prev][Date Next]
Re: (ITS#3824) slapadd/slapindex -q can break db_stat
> > -----Original Message----- From: owner-openldap-bugs@OpenLDAP.org
> > [mailto:owner-openldap- bugs@OpenLDAP.org] On Behalf Of
> > email@example.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.
No, it is pointless to make this a runtime check, since it is impossible
to run with a different version of the BDB library than what was
compiled. The BDB ABI is neither forward nor backward compatible between
> 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.
It depends on the BDB cache size vs the total database size. In general,
there is a noticable speedup in initial queries for a freshly slapadd'd
database when the cache remains intact. Whether it's crucial or not is a
separate question (I think it's not crucial) but it is certainly of some
benefit to keep the cache.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support