db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5258) btree post commit releases latch before committing/aborting purges, possibly allowing other operation on page
Date Sat, 04 Jun 2011 23:55:49 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044417#comment-13044417

Bryan Pendleton commented on DERBY-5258:

Wow! Great find, Mike! Your description is quite clear and your theory makes sense to me.
Your detective work is wonderful to read, thanks very much for taking the time to describe
the sequence of actions that lead to this case.

The patch has a few whitespace issues, I think, but other than that it looked fine to me.

I think that the comment could read  "The commit will clear the latch" rather than
"The commit should clear the latch", as the "should" doesn't quite sound right.

> btree post commit releases latch before committing/aborting purges, possibly allowing
other operation on page
> -------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-5258
>                 URL: https://issues.apache.org/jira/browse/DERBY-5258
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,,,,
>            Reporter: Mike Matrigali
>            Assignee: Mike Matrigali
>         Attachments: DERBY-5258_diff.txt
> From code inspection found the following problem.  BTreePostCommit.purgeCommittedDeletes
gives up the latch in it's finally block, before the internal transaction is
> committed.  The transaction is committed no sync upon return from this routine leaving
a very small window when some other thread could get latch on the page and
> perform operations on the page.
> This can be a problem if for some reason the internal transaction is never committed.
 Purges actually return space to the page, unlike deletes.  In order to backout the 
> purges one must add the rows back, taking up space on the page.  If another tranaction
comes in before the internal transaction is committed and does inserts there may
> be no space for the backout of the purges.  This is why normal delete processing only
sets flags on the rows and purge processing is handled differently.  
> I found this problem while debugging a database submitted as part of DERBY-5248.  I believe
this issue can cause the problem there, but since we have no repro have
> decided to create a new issue to target this specific problem/solution.  Later can close
the other issue if it can never be reproduce after the fix.   In DEBY-5248 there 
> are purges without a commit followed immediated by an insert in another transaction that
is commited and the purge transaction is never committed.  On recovery the
> system tries to abort the internal transaction and eventually trashes the page when it
does not actually have enough space to abort the purge.  See that issue for more
> detail.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message