daver@idiom.com (David Ray) writes: >I'm still using the Perl-4 style DB functions such as dbopen() for my Perl >DB work, and I just ran into a problem. It looks like there is a size >limitation of the key/value data. Above a certain size, trying to set the >DB record causes the script to return a DB error. Last week, I denied the existence of this bug, but it looks as if I'll have to recant. The following message appeared in the Perl5-porters mailing list, and I'll have to look into it. David, could the symptoms you're seeing possibly be caused by a bug as described below? Matthias ----- Matthias Neeracher <neeri@iis.ee.ethz.ch> http://www.iis.ee.ethz.ch/~neeri "One fine day in my odd past..." -- Pixies, _Planet of Sound_ Subject: Bug in Berkeley DB 1.85 Newsgroups: perl.porters-gw Date: Mon, 25 Nov 1996 13:00:02 -0800 From: jon@sems.com (Jonathan Biggar) I thought some of you might be interested in this bug+patch I found in Berkeley DB v1.85 using the hash mode. The bug symptoms are if you store a large value in the database (where large means larger than the database page size), and then replace it will a value that is smaller than the page size, then the key for this value can grow in length by one as stored in the database. This causes future lookups for the value to fail, and sequential access of the database to return a key that was never inserted into the database. This is caused by an off by one error when removing the old value from the database before inserting the new value. I caught this by comparing the cleanup code patched below with the PAGE_INIT macro defined in hash_page.c. Jon Here is the patch: *** hash_bigkey.c.orig Fri Jun 24 08:12:30 1994 --- hash_bigkey.c Sat Nov 23 11:08:52 1996 *************** *** 244,250 **** n -= 2; bp[0] = n; FREESPACE(bp) = hashp->BSIZE - PAGE_META(n); ! OFFSET(bp) = hashp->BSIZE - 1; bufp->flags |= BUF_MOD; if (rbufp) --- 244,250 ---- n -= 2; bp[0] = n; FREESPACE(bp) = hashp->BSIZE - PAGE_META(n); ! OFFSET(bp) = hashp->BSIZE; bufp->flags |= BUF_MOD; if (rbufp)