Re: index corruption (1164) still present in 2.0.15 with db 3.1.17 (ITS#1359)

[leifj@it.su.se]

On Sat, Sep 29, 2001 at 02:27:26PM -0700, Kurt D. Zeilenga wrote:
> At 02:14 PM 2001-09-29, leifj@it.su.se wrote:
> >On Sat, Sep 29, 2001 at 10:51:10AM -0700, Kurt D. Zeilenga wrote:
> >> At 10:39 AM 2001-09-29, leifj@it.su.se wrote:
> >> >The good news is that there was no index curruption with gdbm!
> >> 
> >> Yes, the problems appear to be limited to use of Berkeley
> >> DB's Concurrent DB API. 
> >> 
> >> >I will try a db-3.3.11 version of ldbm now and report back.
> >> 
> >> If you have problems, try undefining HAVE_BERKELEY_DB_THREAD
> >> (portable.h).  This will disable use of the Concurrent DB API
> >> and should resolve the problem (at the expense of concurrency).
> >
> >Hmm... configure left HAVE_BERKELEY_DB_THREAD undefined so I guess
> >I can't test what would have happened. In any case my 70 ops left
> >the index in great shape!
> 
> I am curious as to why HAVE_BERKELEY_DB_THREAD is undefined
> and, if it were defined, whether the problem exists.
> 
> Can you examine config.log and determine why HAVE_BERKELEY_DB_THREAD
> is not set when using DB 3.3.11? 

Damn! It still works with HAVE_BERKELEY_DB_THREAD defined -- configure
failed because of a stupid operator misstake :-( -- which leads me to
doubt my test. Do you think that the fact that I modify objectClass in
my production code and another privately defined attribute in my test
program has anything to do with it?

I will try running my production stuff on gdbm starting tomorrow and
see if that works...

	Cheers Leif