[
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
