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