[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

mhardin@symas.com wrote:
> > -----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.

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
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support