db-derby-dev mailing list archives

[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 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:
10.0.2.1
10.1.1.0
10.1.2.1
and fixed in Apache Release
10.1.3.1
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 10.2.1.6.
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 10.4.1.3 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 ;
CONSTRAINTNAME
|CONSTRAINTID
|CONGLOMERATEID |CONGLOMERATENAME
|CONGLOMERATENUMBER
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------
PK_RS
|e50d80a4-0130-524c-af38-0000001
c6908|94bc40a2-0130-524c-af38-0000001c6908|SQL110602144057310
|1153
ij> select * from sys.sysconglomerates where conglomeratenumber=1153;
SCHEMAID |TABLEID |CONGLO
MERATENUMBER |CONGLOMERATENAME
|ISIN&|DESCRIPTOR
|ISCO&|CONGLOMERATEID
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------------------------------------------------
23ce809c-0130-524c-af38-0000001c6908|6c44409f-0130-524c-af38-0000001c6908|1153
|SQL110602144057310
|true |UNIQUE BTR
EE (&|true |94bc40a2-0130-524c-af38-0000001c6908
23ce809c-0130-524c-af38-0000001c6908|6c44409f-0130-524c-af38-0000001c6908|1153
|SQL110602144057610
|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 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