[ 
https://issues.apache.org/jira/browse/DERBY-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-4639:
----------------------------------

    Component/s: SQL

I believe issue is that is that system wants the name of the file that is going 
to be associated with the
table before doing the system catalog interaction, and to get this it must 
first create the file.  Then it does a system catalog insert which will fail if 
the matching table name exists.  This insert does the proper system catalog 
locking to insure that others don't create the table at the same time.

If a fix is made to do the catalog lookup first a few things should be tested 
for:
o) does the new check handle the race where someone else tries to create the 
table after the check
     but before the code can create the table.
o) does the new check make create table less concurrent, ie. does it possibly 
stop others from 
    creating other tables with names similar to this one.  Basically what 
isolation level locking is going
    to happen with the check in the case of non-existent data.  A serializable 
check will get a previous
    key lock and then will prevent inserts of any key between that key and the 
next in the index.

The safest thing to do might be to do the insert as is but earlier with no 
container information, and then
do a subsequent update of the row to add the container info.

> Repeatedly issuing a CREATE TABLE against a table that already exists causes 
> Derby to soak up disk space
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4639
>                 URL: https://issues.apache.org/jira/browse/DERBY-4639
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.3.0
>            Reporter: David Van Couvering
>            Assignee: Lily Wei
>         Attachments: CreateExistedTableDBGrow.java
>
>
> Create a program that issues CREATE TABLE against an existing table every 
> five seconds, ignoring the exception that the table already exists.  
> Observe that the database directory starts growing by about 1 MB every 
> minute.  You can also see the number of .dat files growing in seg0 at a 
> constant rate.
> Workaround is to check to see if the table exists first before issuing the 
> CREATE TABLE statement, but this is still a bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to