db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.
Date Fri, 20 Jul 2012 19:49:35 GMT

     [ 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

        

Mime
View raw message