You are viewing a plain text version of this content. The canonical link for it is here.

Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <ji...@apache.org> on 2010/12/01 02:03:11 UTC

[jira] Created: (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.

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
    Affects Versions: 10.6.2.1, 10.6.1.0, 10.5.3.0
            Reporter: Mike Matrigali
            Assignee: Mike Matrigali


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.
-
You can reply to this email to add a comment to the issue online.

[jira] [Commented] (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.

Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.

    [ 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

[jira] [Updated] (DERBY-4923) update of a long row can fail with ERROR nospc: nospc.U exception.

Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.

     [ https://issues.apache.org/jira/browse/DERBY-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-4923:
----------------------------------

    Assignee:     (was: Mike Matrigali)

i had plans to look at this, but not top of my list.  unassiging it for now and will change if I am actively working on it.
                
> 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.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