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 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 21:51:47 GMT

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

Kathey Marsden commented on DERBY-5249:

Thank you Mike for the pointers. Here are some answers to some of your questions.

1) Determine exactly the releases that built the bad system catalog. 

Apache Released Versions with bad catalogs:

and fixed in Apache Release

10.2 forward does not have the problem.
The exact fix for the bad catalogs on the 10.1 branch was revision 411398.
DERBY-655 getImportedKeys returns duplicate rows in some cases.
I verified this by backing that fix out of 10.1.
(Note DERBY-655 introduced  a regression, DERBY-1854. Also note I was wrong in my initial
theory that DERBY-1854 was what fixed the dup conglomerate, but it looks like while DERBY-655
corrected the dup it introduced some other bad catalog problem which would cause corruption
on compress. DERBY-1854 went into the head of the 10.1 and 10.0 branches (never released).
 Both DERBY-655 and DERBY-1854 fexes  were in

2) determine exactly the releases that could drop the bad system catalog. Maybe looking at
how drop worked 

The drop error was introduced in Apache Release with the fix for DERBY-3299 Uniqueness
violation error (23505) occurs after dropping a PK constraint if there exists a foreign key
on the same columns.  This was a pretty extensive fix and had upgrade implications so was
not backported, so all 10.4, 10.5, 10.6, 10.7, and 10.8 releases are affected by the drop
problem, but lower branches are not.


3) You have posted the bad catalog entries, what is the correct catalog entries. 
Here is an example with trunk and the repro_create script.  This is actually surprising to
me as there are still two entries in sys.sysconglomerates but the join query with sys.sysconstraints
and sys.syskeys returns a single row.  I think maybe the problem with the old one is that
both say UNIQUE but I am not sure about that.  I need to understand it better.

ij> select c.constraintname, c.constraintid,  cong.conglomerateid, cong.conglome
ratename, cong.conglomeratenumber  from sys.sysconglomerates cong, sys.syskeys k
, sys.sysconstraints c where c.constraintname = 'PK_RS' and c.constraintid =k.co
nstraintid and k.conglomerateid = cong.conglomerateid  ;



ij> select * from sys.sysconglomerates where conglomeratenumber=1153;
SCHEMAID                            |TABLEID                             |CONGLO
                                                               |true |UNIQUE BTR
EE (&|true |94bc40a2-0130-524c-af38-0000001c6908
                                                               |true |BTREE (1)
     |true |070a00b0-0130-524c-af38-0000001c6908

2 rows selected

for 4 and 5 I am going to do some more debugging and also try to understand what is really
wrong with the old catalogs. Any insight appreciated.

> A table created with 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:
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>         Attachments: my10db.zip, repro_create.sql, repro_create.sql
> In  there was some bug that caused a duplicate entry in sys.sysconglomerates.
> After running the attached repro_create.sql with, 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 -
> 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 
> (can be accessed at http://svn.apache.org/repos/asf/db/derby/jars/
> run the attached script repro_create.sql;
> connect with the latest on the trunk or 10.5 branch
> The table will not drop. The work around is to drop the table with the old version

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

View raw message