[
https://issues.apache.org/jira/browse/DERBY-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419620#comment-13419620
]
Mike Matrigali commented on DERBY-4923:
---------------------------------------
I do believe it is always a bug if a NoSpaceOnPage leaks out to a user. There
is a normal case where we can't insert and/or update keys in indexes over a
certain size, but I think that
gets wrapped in a different exception.
If the code were acting correctly then it would have reserved enough space such
that the operation is not leaking the exception. So at least in the cases that
I have debugged in the
past the bug is not in the operation that is failing, it is in a previous
operation that lead to the page getting to state with not enough reserved space
to do the operation. There are
2 things to handle. First is that the head of a row in a base table (heap) can
never move off its page, so you must reserve enough space in the head row/page
so that in the worst
case you can change the row to one that just has the head of row pointing to a
linked list of all the other columns on another page. The second case is
handling the "middle" of the
row on another page. Again similarly the design is to reserve enough space for
the row such that if you need to expand it there is always enough space in
worst case to just make
it a pointer yet another chunk somewhere. It gets tricky in that a row might
be smaller than what is necessary in the worst case to be one of these
pointers.
The mostly likely place for this bug to happen would be in UpdateOperation and
UpdateFieldOperation as these result in expanding the length of the row in
place.
CopyRowsOperation prechecks that the destination of the rows has space and
maintains a latch so that it is guaranteed. I remember a NoSpaceOnPage bug in
the past in this one
where the bug was in the check not accounting for the correct change in
compressed size of the page field, so in this case the bug was in the operation
and not in the previous operaition.
InsertOperation is the normal path for NoSpaceOnPage exceptions, I expect that
somehow the code is set to catch these as it is the normal way to tell to
insert a row somewhere else
rather than where it does not fit.
> 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
