db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <david.vancouver...@gmail.com>
Subject Re: Very bad disk space leak in Derby
Date Mon, 03 May 2010 21:37:49 GMT
I am sorry to say I didn't save the database directory and have since worked
around the problem by checking to see if the table exists before creating
it, so I don't know the names of the files.  If it's important, I'll comment
out my changes for now and recreate the problem and tell you what I'd see.

However, it definitely never got cleaned up.  Our QA person had his system
up for a few days and it went from a few MB to 5GB and never went back down.
 Shutting down and rebooting the database also had no effect.  The only time
I ever saw it shrink back down was when I upgraded from 10.4 to 10.5


On Mon, May 3, 2010 at 2:25 PM, Mike Matrigali <mikem_app@sbcglobal.net>wrote:

> what are the names of the new files after the transaction that
> tried to create the existing table them commits?  If they are still c*.dat
> then there
> is definitely something wrong.  If they start with a different letter
> then it could be that derby is acting as expected and just did not get
> around to cleaning them
> yet.  I believe it does this at checkpoint time.  The assumption being
> that normally this case is just drop table and not needed to be optimized.
> I have not looked at the code but my guess is that create table is
> counting on a unique key violation to tell whether a table exists
> or not.  To do this it has to do an insert and to do the insert it
> needs the name of the file which only exists after the file is
> created.
> David Van Couvering wrote:
>> Yes, it does sound like a bug.  I'll log a JIRA
>> On Fri, Apr 30, 2010 at 6:50 PM, Bryan Pendleton <
>> bpendleton.derby@gmail.com <mailto:bpendleton.derby@gmail.com>> wrote:
>>        As I mentioned to Knut, I try to issue a CREATE TABLE each time
>>        I connect, and ignore the exception saying it already exists if
>>        the table is already there.
>>    If this is leaking a conglomerate each time (creating a .dat file but
>>    never deleting it), that seems like a bug to me.
>>    thanks,
>>    bryan
>> --
>> David W. Van Couvering
>> http://www.linkedin.com/in/davidvc
>> http://davidvancouvering.blogspot.com
>> http://twitter.com/dcouvering

David W. Van Couvering


View raw message