db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-4275) Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
Date Fri, 24 Jun 2011 09:38:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054327#comment-13054327
] 

Knut Anders Hatlen commented on DERBY-4275:
-------------------------------------------

During SYSCS_COMPRESS_TABLE we invalidate dependent statements three times, and all of them
happen before any changes have been made to the data dictionary. With the patch, this is changed
to two invalidations before the DD changes and one after the DD is updated.

The first two invalidations are done by the general alter table machinery. The compress table
implementation was moved into alter table in 10.5 (DERBY-1062). It may be that the earlier
invalidation was needed before that change, but now that we have the alter table machinery
doing early invalidation in any case, the bug mentioned in the comments (bug 3653) is probably
handled even if we move the compress-specific invalidation after the data dictionary changes.

> 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
>            Assignee: Knut Anders Hatlen
>              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

        

Mime
View raw message