[DERBY-691] committed deleted row space reclamation may be missed if delete is actually an aborted insert.

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 10.0.2.0
• Fix Version/s: 10.12.1.1
• Component/s: Store
• Assignee: Mike Matrigali
• Reporter: Mike Matrigali
• Created: 09/Nov/05 04:48
• Updated: 09/Sep/16 09:51
• Resolved: 12/Dec/14 20:17

Description

The system should queue post commit activity in the case of an aborted insert which internally is implemented as a delete. In this case post commit should be queued following the same rules as straight line delete currently. The result is that if the last delete on a page is actually an aborted insert then space on that page may never be automatically reclaimed (It is always can be reclaimed by hand using the space reclamation system procedures).

Note that a duplicate key insert error internally generates this case. It first inserts the row into the base table. Then it attempts to insert a row into the unique index and fails. As part of the failure it aborts the statement which turns the insert into a delete as part of the undo.

Issue Links

• incorporates: DERBY-4057 Space is not reclaimed if transaction is rolled back
• is duplicated by: DERBY-4056 Space is not reclaimed when attempting to insert row that violates UNIQUE constraint
• is related to: DERBY-692 improve post commit committed delete handling when system crashes
• is related to: DERBY-5356 Tracking for Derby space reclamation issues
• relates to: DERBY-4182 SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE does not reclaim space lost from an aborted insert