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] [Created] (DERBY-5258) btree post commit releases latch before committing/aborting purges, possibly allowing other operation on page
Date Wed, 01 Jun 2011 17:50:47 GMT
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: 10.8.1.2, 10.7.1.1, 10.6.1.0, 10.5.3.0, 10.4.2.0, 10.3.3.0, 10.2.2.0,
10.1.3.1
            Reporter: Mike Matrigali
            Assignee: Mike Matrigali


>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

Mime
View raw message