From: Lachlan Andrew <lha@us...> - 2003-07-18 01:54:35
Yes, this is the "page leak" that was discussed late last month with=20
Krzysztof Gorgolewski. My patch tickles a bug in the existing code=20
to write a page -- unless the page is flushed from the cache after=20
writing, any new chain which is introduced is lost. Without my new=20
code, the only time the page is written is when it is about to be=20
flushed from the cache, so the bug doesn't manifest itself. (I wrote=20
an email describing all of this, but I can't find it in my outbox, so=20
I may not have actually sent it ):
The best solution is to fix the original bug, but that involves yet=20
more changes to db.h etc to allocate room in each page header for the=20
list of overflow pages, or some similar. A simple way of avoiding the=20
problem is, of course, to remove all my new code to flush the cache=20
periodically, which is made redundant by using the "standalone"=20
database for the "weak compression" free list. As a hack until I get=20
time to remove the flushing completely, CVS currently disables cache=20
flushing by setting wordlist_cache_dirty_level to a very large=20
value, so it *shouldn't* be a problem in the latest snapshot. What=20
version are you using to generate the problem?
I'm off overseas for a month tomorrow, so I don't have time to work on=20
ht://Dig at all. If you like, feel free to revert to the original=20
before I started messing things up...
On Tue, 15 Jul 2003 11:08, Neal Richter wrote:
> =09I'm seeing a startling difference in db.word.db sizes before and
> after your changes to mp_alloc.c and others.
> 77824 Jul 14 18:45 db.words.db
> 184320 Jul 14 18:24 db.words.db
> If I use htdump to dump these files, the dump is exactly the same.
> Ack! Do you see this?
> Neal Richter
> Knowledgebase Developer
> RightNow Technologies, Inc.
> Customer Service for Every Web Site
> Office: 406-522-1485
Get latest updates about Open Source Projects, Conferences and News.