db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5249) A table created with 10.0.2.1 with constraints cannot be dropped with 10.5 due to NullPointerException with insane build or ASSERT FAILED Failed to find sharable conglomerate descriptor for index conglomerate with sane build
Date Thu, 02 Jun 2011 17:37:49 GMT

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

Kathey Marsden commented on DERBY-5249:
---------------------------------------

I am trying to understand the situation when we need to deal with the duplicate row 
from the 10.0 db.  In the problematic database we see:

select c.constraintname, c.constraintid,  cong.conglomerateid, cong.conglomerate
name, cong.conglomeratenumber  from sys.sysconglomerates cong, sys.syskeys k, sy
s.sysconstraints c where c.constraintname = 'PK_RS' and c.constraintid =k.constr
aintid and k.conglomerateid = cong.conglomerateid  ;
CONSTRAINTNAME
                                                |CONSTRAINTID
     |CONGLOMERATEID                      |CONGLOMERATENAME

           |CONGLOMERATENUMBER
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------
PK_RS
                                                |8ca44062-0130-4d54-e465-0000002
87600|848c0061-0130-4d54-e465-000000287600|SQL110601033139780

           |785
PK_RS
                                                |8ca44062-0130-4d54-e465-0000002
87600|848c0061-0130-4d54-e465-000000287600|SQL110601033139890

           |785


and 

ij> select * from sys.sysconglomerates where conglomeratenumber =785;
SCHEMAID                            |TABLEID                             |CONGLOMERATENUMBER
 |CONGLOMERATENAME
                                                               |ISIN&|DESCRIPTOR     |ISCO&|CONGLOMERATEID
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------------------------------------------------
1c16805c-0130-4d54-e465-000000287600|2c44c05e-0130-4d54-e465-000000287600|785
              |SQL110601033139780
                                                               |true |UNIQUE BTREE (&|true
|848c0061-0130-4d54-e465-000000287600
1c16805c-0130-4d54-e465-000000287600|2c44c05e-0130-4d54-e465-000000287600|785
              |SQL110601033139890
                                                               |true |UNIQUE BTREE (&|true
|848c0061-0130-4d54-e465-000000287600


The second entry for conglomerate number 785 appeared upon creation of the foreign key.
I will attached the zipped database my10db.zip.  I am thinking at a high level that describeSharedConglomerate
should return this second conglomerate but am not totally sure. 




> A table created with 10.0.2.1 with constraints cannot be dropped with 10.5 due to NullPointerException
with insane build or ASSERT FAILED Failed to find sharable conglomerate descriptor for index
conglomerate  with sane build
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5249
>                 URL: https://issues.apache.org/jira/browse/DERBY-5249
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.3.0
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>         Attachments: my10db.zip, repro_create.sql, repro_create.sql
>
>
> In 10.0.2.1  there was some bug that caused a duplicate entry in sys.sysconglomerates.
> After running the attached repro_create.sql with 10.0.2.1, you will see two rows returned
instead of one with:
> select c.constraintname, c.constraintid,  cong.conglomerateid, cong.conglomeratename
 from sys.sysconglomerates cong, sys.syskeys k, sys.sysconstraints c where c.constraintname
= 'PK_RS' and c.constraintid =k.constraintid and k.conglomerateid = cong.conglomerateid  ;
> I am not sure what practical impact this has with 10.0 as you can still drop the table
s.rs with that version.
> On connecting to the  database with 10.5, either soft or hard upgrade with 10.5.3.2 -
1103924
> DROP TABLE S.RS  fails with:
> Caused by: java.sql.SQLException: Java exception: 'ASSERT FAILED Failed to find
> sharable conglomerate descriptor for index conglomerate # 785: org.apache.derby.
> shared.common.sanity.AssertFailure'.
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
> eptionFactory.java:45)
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransport
> AcrossDRDA(SQLExceptionFactory40.java:119)
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
> xceptionFactory40.java:70)
>         ... 17 more
> Caused by: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Fa
> iled to find sharable conglomerate descriptor for index conglomerate # 785
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(Sanit
> yManager.java:162)
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(Sanit
> yManager.java:147)
>         at org.apache.derby.iapi.sql.dictionary.ConglomerateDescriptor.describeS
> haredConglomerate(ConglomerateDescriptor.java:638)
>         at org.apache.derby.iapi.sql.dictionary.ConglomerateDescriptor.drop(Cong
> lomerateDescriptor.java:428)
>         at org.apache.derby.iapi.sql.dictionary.ConstraintDescriptor.drop(Constr
> aintDescriptor.java:738)
>         at org.apache.derby.impl.sql.execute.DDLSingleTableConstantAction.dropCo
> nstraint(DDLSingleTableConstantAction.java:144)
>         at org.apache.derby.impl.sql.execute.DDLSingleTableConstantAction.dropCo
> nstraint(DDLSingleTableConstantAction.java:107)
>         at org.apache.derby.impl.sql.execute.DropTableConstantAction.dropAllCons
> traintDescriptors(DropTableConstantAction.java:315)
>         at org.apache.derby.impl.sql.execute.DropTableConstantAction.executeCons
> tantAction(DropTableConstantAction.java:222)
>         at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.ja
> va:61)
>         at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Generi
> cPreparedStatement.java:416)
>         at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPre
> paredStatement.java:297)
>         at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedState
> ment.java:1235)
>         ... 10 more
> and with an insane build with a NullPointerException:
> java.lang.NullPointerException 
>       at 
>    org.apache.derby.iapi.sql.dictionary.ConglomerateDescriptor.drop(Unknown 
>    Source) 
>       at 
>    org.apache.derby.iapi.sql.dictionary.ConstraintDescriptor.drop(Unknown 
>    Source) 
>       at 
>    org.apache.derby.impl.sql.execute.DDLSingleTableConstantAction.dropConst 
>    raint(Unknown Source) 
>       at 
>    org.apache.derby.impl.sql.execute.DDLSingleTableConstantAction.dropConst 
>    raint(Unknown Source) 
>       at 
>    org.apache.derby.impl.sql.execute.DropTableConstantAction.dropAllConstra 
>    intDescriptors(Unknown Source) 
>       at 
>    org.apache.derby.impl.sql.execute.DropTableConstantAction.executeConstan 
>    tAction(Unknown Source) 
>       at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown 
>    Source) 
>       at 
>    org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
>    Source) 
>       at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
>    Source) 
>       at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
>    Source) 
>       at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) 
>       at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown 
>    Source) 
> Still need to figure out the exact versions affected, when the dup row was fixed, and
when the drop stopped working.
> To reproduce connect to a database with 10.0.2.1 
> (can be accessed at http://svn.apache.org/repos/asf/db/derby/jars/10.0.2.1)
> run the attached script repro_create.sql;
> connect with the latest on the trunk or 10.5 branch
> DROP TABLE S.RS;
> The table will not drop. The work around is to drop the table with the old version 10.0.2.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message