[
https://issues.apache.org/jira/browse/DERBY-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4923:
---------------------------------
Attachment: derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff
Comments on DERBY-4577 and DERBY-4923 suggest that NoSpaceOnPage is a transient
signal passed between methods inside StoredPage. If you grep the codeline, you
see that StoredPage is the only class which mentions this exception. Low level
logging methods throw NoSpaceOnPage to tell their callers that there isn't
enough room on the page for the operation. The callers (in StoredPage) are
supposed to allocate more space and then retry the operation. It seems that
NoSpaceOnPage should never leak out of StoredPage. It should never escape to
methods higher on the call stack. Does that sound correct?
I am attaching derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff. This patch
changes NoSpaceOnPage, making it directly extend Exception so that it is no
longer a StandardException. With this change you can see that it may be
possible for NoSpaceOnPage to escape outside StoredPage to methods in the
following classes:
UpdateOperation
CopyRowsOperation
DirectActions
UpdateFieldOperation
InsertOperation
There may be reasons why some of these callers can be confident that they won't
ever see a NoSpaceOnPage exception. However, I don't understand how we can
prove that assertion for any of these classes. It's clear that NoSpaceOnPage
can leak up to at least one of these classes (UpdateOperation), perhaps in
several ways given the number of bugs we have seen with this stack trace.
Is there some way that we can prove that NoSpaceOnPage won't escape to any of
the other calling classes?
Thanks,
-Rick
> update of a long row can fail with ERROR nospc: nospc.U exception.
> ------------------------------------------------------------------
>
> Key: DERBY-4923
> URL: https://issues.apache.org/jira/browse/DERBY-4923
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.3.0, 10.6.1.0, 10.6.2.1
> Reporter: Mike Matrigali
> Labels: derby_triage10_8
> Attachments: DERBY_4923.java,
> derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff, derby.log,
> derby4923repro.diff
>
>
> An update of a row fails with a nospc.U exception. If there is space on the
> disk then an update should never fail for a space
> issue. The code is meant to always reserve enough space on a page such that
> if an expanding update happens that does not
> fit, it should in the worst case change the row to an overflow row pointer
> and put the rest in a linked overflow chain.
> The following set of circumstances will cause this bug (not sure which are
> exactly needed - just what i did to
> cause the repro), I will be attaching a test case:
> The row being updated has the following characteristics:
> o located on 4k page
> o 2 colum row with 2nd column a blob column
> o the row is a long row with first piece having 1st column on main page,
> and the 2nd piece having just blob column on overflow page.
> o before the update there is 0 free space on the overflow page.
> o the update causes the blob column to expand past 4k
> Caused by: java.sql.SQLException: nospc.U
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
> ... 39 more
> Caused by: ERROR nospc: nospc.U
> at
> org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:4155)
> at
> org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255)
> at
> org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(UpdateOperation.java:106)
> at
> org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8625)
> at
> org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1062)
> at
> org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:486)
> at
> org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:569)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1241)
> ... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
