db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Very bad disk space leak in Derby
Date Mon, 03 May 2010 21:25:23 GMT
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

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

View raw message