[
https://issues.apache.org/jira/browse/DERBY-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043140#comment-13043140
]
Kathey Marsden commented on DERBY-5249:
---------------------------------------
So in the bad catalogs, the conglomerateid for the two rows is the same. This
is what DERBY-655 fixed. In the current code the method:
public ConglomerateDescriptor describeSharedConglomerate(
ConglomerateDescriptor [] descriptors, boolean ignoreThis)
if ignoreThis is set, has the code below to determine whether we are looking at
"this" as we loop through the two descriptors passed in
// Skip if ignoreThis is true and it describes "this".
if (ignoreThis &&
getUUID().equals(descriptors[i].getUUID()))
{
continue;
}
With the bad catalogs the getUUID() matches for both entries so we continue
and do not return the shared descriptor. A quick hack to return the second
match allows the table to be dropped, but I am not sure that is the right fix
or if I might actually return "this" in some instances by doing that.
describeSharedConglomerate is currently only used by drop.
> 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
