[
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.