[
https://issues.apache.org/jira/browse/DERBY-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4275:
--------------------------------------
Attachment: invalidate-after.diff
The problem shown by CompressDBTest2.java looks like DERBY-3683.
The "conglomerate does not exist" errors in CompressDBTest1.java seem to happen
because AlterTableConstantAction.compressTable() invalidates the prepared
statements before it compresses the table. Executing statements may then try to
recompile before the table has been compressed, and they continue using the old
conglomerate since they're not invalidated again.
I tried to delay the invalidation until the new compressed conglomerates had
been created and the system tables were updated (see attached patch), and that
made the CompressDBTest1 repro complete with no failures.
There is a comment saying that the early invalidation was intentional to work
around a bug. Looking at an earlier version of the comment, it referred to a
bug 3653 where some statements didn't recompile if the invalidation happened
later. I don't know what kind of statements had that problem, though. I'll run
the regression tests to see if they show anything. (Truncate table has a
similar comment and would probably need a similar fix.)
There's always the possibility to invalidate statements both before and after
compressing the table, but it really should be enough to do it once.
> Query executions fail when compressing a table using
> SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
> -------------------------------------------------------------------------------------
>
> Key: DERBY-4275
> URL: https://issues.apache.org/jira/browse/DERBY-4275
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.4.1.3
> Reporter: Sai Pullabhotla
> Labels: derby_triage10_5_2
> Attachments: CompressDBTest1.java, CompressDBTest2.java,
> invalidate-after.diff
>
>
> Query executions (SELECT and/or UPDATE) fail with serious exceptions while
> the table is being compressed using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE. The
> compression eventually finishes normally, but the queries keep failing with
> the same error until the database is rebooted. More information about this
> can be found on the Derby mailing list at
> http://www.nabble.com/Issue-with-SYSCS_UTIL.SYSCS_COMPRESS_-TABLE-td23892893.html.
> The exception stacktrace is below:
> Caused by: java.sql.SQLException: The conglomerate (71,409) requested does
> not exist.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source)
> at
> org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
> ... 25 more
> Caused by: ERROR XSAI2: The conglomerate (71,409) requested does not
> exist.
> at
> org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at
> org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source)
> at
> org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.<init>(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.JoinResultSet.openRight(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.UnionResultSet.getNextRowCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.getRowFromResultSet(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.getNextRowFromRS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
