db-derby-dev mailing list archives

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

    [ 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
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
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:,,
>            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


View raw message