db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4244) ALTER TABLE Sanity ASSERT in add column with autocommit off
Date Fri, 03 Jul 2009 22:08:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727148#action_12727148
] 

Bryan Pendleton commented on DERBY-4244:
----------------------------------------

If I change the next-to-last SQL statement from

  alter table t0 add column c2 int not null default 0 primary key;

to

  alter table t0 add column c2 int not null default 0;

then the problem does not occur. This suggests to me that the problem involves
the cleanup that is performed after this error is encountered

ERROR X0Y58: Attempt to add a primary key constraint to table '"APP"."T0"' failed because
the table already has a constraint of that type.  A table can only have a single primary key
constraint.

I can see in derby.log that the stack trace at the time of this error looks like this:

        at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
        at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:541)
        at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:64)
        at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:297)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:625)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
        at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
        at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:521)
        at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:363)
        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261)
        at org.apache.derby.impl.tools.ij.Main.go(Main.java:222)
        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:177)
        at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
        at org.apache.derby.tools.ij.main(ij.java:59)

This suggests to me that the next step is to study the error handling that is performed in
this
part of the code; specifically whether AlterTableConstantAction.executeConstantAction isn't
properly cleaning everything up when the error occurs.


> ALTER TABLE Sanity ASSERT in add column with autocommit off
> -----------------------------------------------------------
>
>                 Key: DERBY-4244
>                 URL: https://issues.apache.org/jira/browse/DERBY-4244
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
10.5.1.1, 10.6.0.0
>            Reporter: Bryan Pendleton
>            Assignee: Eranda Sooriyabandara
>            Priority: Minor
>
> While working with Eranda on DERBY-4187, I stumbled across an apparent ALTER TABLE bug.
> Here's a script which reproduces the problem for me:
> autocommit off;
> create table t0(c1 int not null constraint p1 primary key);
> alter table t0 add column c1 int;
> alter table t0 add column c2 int not null default 0 primary key;
> alter table t0 add column c2 int not null default 0;
> The "autocommit off" is crucial; otherwise the problem does not reproduce.
> Here's the detailed assertion failure:
> 2009-05-23 15:01:17.436 GMT Thread[main,5,main] (XID = 146), (SESSIONID = 1), (DATABASE
= brydb), (DRDAID = null), Failed Statement is: alter table t0 add column c2 int not null
default 0
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED column_id = 1format_ids.length
= 2format_ids = [I@1321f5
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
>         at org.apache.derby.impl.store.access.heap.Heap.addColumn(Heap.java:418)
>         at org.apache.derby.impl.store.access.RAMTransaction.addColumnToConglomerate(RAMTransaction.java:618)
>         at org.apache.derby.impl.sql.execute.AlterTableConstantAction.addNewColumnToTable(AlterTableConstantAction.java:1325)
>         at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:449)
> Here's the relevant section of Heap.java:
>             if (column_id != format_ids.length)
>             {
>                 if (SanityManager.DEBUG)
>                     SanityManager.THROWASSERT(
>                         "column_id = " + column_id +
>                         "format_ids.length = " + format_ids.length +
>                         "format_ids = " + format_ids);
>                 throw(StandardException.newException(
>                         SQLState.HEAP_TEMPLATE_MISMATCH,
>                         new Long(column_id),
>                         new Long(this.format_ids.length)));
>             }

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


Mime
View raw message