Greetings all, I think I've found the problem...
The compressed write routine (CDB___memp_cmpr_write) creates an overflow chain when the compressed page is large, but the existence of this chain is only recorded on disk and not in memory. Unless the page is read before being written again, the old chain is "lost". (You could argue that this wasn't a bug, since the old code only wrote pages when they were being discarded from cache, but it certainly isn't defensive programming!) It allocates the list of pages (not just the pages themselves) only when there is an overflow. In ..._write, this is currently allocated using malloc. Allocating it from the memory pool is necessary if the list is to be kept after writing, but will cause the same problem of recursion which occrs when the ..._weakcmpr database shares the memory pool. The only solution I can see is statically allocating room for the overflow list in every memory page. This is an overhead of about 64 bytes per page. I'd like to delay that sort of rewrite until after 3.2.0b5 is out. Thoughts? Lachlan On Sun, 29 Jun 2003 18:57, Lachlan Andrew wrote: > I think that my ..._dirty_level kludge is just tickling an existing > bug (tickling with sandpaper, perhaps!). The kludge is no longer > necessary in the last two snapshots. -- [EMAIL PROTECTED] ht://Dig developer DownUnder (http://www.htdig.org) ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ htdig-general mailing list <[EMAIL PROTECTED]> To unsubscribe, send a message to <[EMAIL PROTECTED]> with a subject of unsubscribe FAQ: http://htdig.sourceforge.net/FAQ.html
