db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (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 18:03:48 GMT

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

Mike Matrigali commented on DERBY-5249:

I don't know this code so can't answer details but here is what I would do to debug this.
 From what you have
posted so far I believe that what we are looking at is there was a bug in one or more very
old releases that
created bad system catalog entries.  Some number of problems resulted from these entries but
not sure what.
A number releases after that bug was fixed could still drop the tables with the bad system
catalogs.  Then at
some point a new bug was fixed but as a side effect could no longer deal with buggy system
catalogs on drop.

1) Determine exactly the releases that built the bad system catalog.
2) determine exactly the releases that could drop the bad system catalog.  Maybe looking at
how drop worked
    before can help you understand what needs to be done now.  
3) You have posted the bad catalog entries, what is the correct catalog entries.
4) Can you describe overall what is the problem that current drop is encountering - not just
what you have
    already posted but something higher level.  For instance did we already drop an index
but didn't catch the 
    extra row and now when we see the extra row it being an orphan is causing the problem.
    This is probably more clear once
    you post answer to 3.  For instance do we just have bad rows in catalogs, or are there
"extra" real files that
    need to be dealt with.
5) The routine you mention changing has a name that seems like a utility routine that may
be used for more than 
    just drop.  If so it may not be appropriate to make it handle buggy catalog entries. 
It would seem reasonable to
    limit the fix to just allowing a drop of the bad tables.  Worst case maybe we have to
handle this as a fix to 
    catalogs on upgrade but that would be messy.  It might be cleaner if we could somehow
recognize the problem
    and possible fork off to a one off set of code.  

> 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