From: Lachlan A. <lh...@us...> - 2003-06-24 13:10:56
|
Greetings, Sorry for the delay in replying -- busy at work... Yes, I didn't think of the database location at all :( I don't think it is an issue of "tweaking". As long as the=20 environment is not the *same* environment as the rest of the=20 database, it will not share the cache. We could have another=20 environment with all the same parameters. (However we would probably=20 not want a cache, since the file shouldn't be used often.) Yes, we should eventually update the underlying BDB code, but perhaps=20 after 3.2.0b5 is out :) Cheers, Lachlan On Tue, 24 Jun 2003 09:06, Neal Richter wrote: > Here's Lachlan's diff to db/mp_cmpr.c > > < if(CDB_db_create(&dbp, dbenv, 0) !=3D 0) > --- > > >/* Use *standalone* database, to prevent recursion when writing > > pages */ > > /* from the cache, shared with other members of the > > environment */ > > if(CDB_db_create(&dbp, NULL, 0) !=3D 0) > > My hunch is that this is a rather 'blunt' fix. It seems likely > that their is a slight problem with the DB_ENV we use... maybe it > needs to be tweaked before the db_create call if the compression is > enabled?? > > The __db_env struct is fairly large, but most of it seems to be > function-pointers. There are a number of variables for Locking, > Logging, Transactions, Memory-pool, and some other flags. > > I'm looking to see what effect this will have. There are a number > of important looking fields in __db_env... some having to do with > db-filename sematics and location. > > I can't find much yet on what everything defaults to (if that is > the right term) when standalone is used. > > I also think we need to look at how we can merge our changes with > at least the next version 'up' of our BDB version at some point > this year. --=20 lh...@us... ht://Dig developer DownUnder (http://www.htdig.org) |