[
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)
