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] [Comment Edited] (DERBY-4057) Space is not reclaimed if transaction is rolled back
Date Sun, 09 Nov 2014 18:41:33 GMT

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

Mike Matrigali edited comment on DERBY-4057 at 11/9/14 6:40 PM:
----------------------------------------------------------------

I think your understanding is correct.  The intent is to make the space reclaiming process
of
an aborted insert to match as closely as possible the existing behavior of space reclamation
of a committed delete.  The current system does nothing for the aborted insert case so that
space is often not reclaimed unless the user runs one of the manual compress calls.

In both cases it is necessary to delay any reclaiming of the space on a page until after the
transaction has successfully committed or aborted.  This insures that redo recovery of the
committed transaction and aborted transactions will always succeed.  If we removed the
space of a delete before commit some other transaction could use that space before we
committed and then the abort of the delete could find there was not enough space to put
the data back on the page. 

The work gets queued after commit or abort.  Usually this work is then done async to the
user thread by the raw store daemon.  This is often an issue with some intermittent test results
across platforms that
"expect" some amount of space reclamation, but sometimes get different results.


was (Author: mikem):
I think your understanding is correct.  The intent is to make the space reclaiming process
of
an aborted insert to match as closely as possible the existing behavior of space reclamation
of a committed delete.

In both cases it is necessary to delay any reclaiming of the space on a page until after the
transaction has successfully committed or aborted.  This insures that redo recovery of the
committed transaction and aborted transactions will always succeed.  If we removed the
space of a delete before commit some other transaction could use that space before we
committed and then the abort of the delete could find there was not enough space to put
the data back on the page. 

The work gets queued after commit or abort.  Usually this work is then done async to the
user thread by the raw store daemon.  This is often an issue with some intermittent test results
across platforms that
"expect" some amount of space reclamation, but sometimes get different results.

> Space is not reclaimed if transaction is rolled back
> ----------------------------------------------------
>
>                 Key: DERBY-4057
>                 URL: https://issues.apache.org/jira/browse/DERBY-4057
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.1.1
>            Reporter: Kathey Marsden
>            Assignee: Mike Matrigali
>              Labels: derby_triage10_5_2, derby_triage10_9
>         Attachments: DERBY-4057_initial_prototype_patch.diff
>
>
> If I repeatedly insert into a clob table and rollback the the transaction the space is
not reclaimed and the number of allocated pages continues to grow.   I will add a test case
to ClobReclamationTest and reference this bug.
> DERBY-4056 may be a special case of this bug, but I thought I would file a bug for the
general issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message