[
https://issues.apache.org/jira/browse/DERBY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671304#action_12671304
]
Kathey Marsden commented on DERBY-4050:
---------------------------------------
The offending code is similar to the code Mike mentioned, but a little later:
// Reclaiming a long column chain due to update. The
long column
// chain being reclaimed is the before image of the
update
// operation.
//
long headPageId =
((PageKey)headRecord.getPageId()).getPageNumber();
StoredPage headRowPage =
(StoredPage)containerHdl.getPageNoWait(headPageId);
if (headRowPage == null)
{
// Cannot get page no wait, try again later.
tran.abort();
if (work.incrAttempts() < 3)
return Serviceable.REQUEUE;
else
return Serviceable.DONE;
}
If I bump it to work.incrAttempts() < 10000 I see no growth.
But my SpaceTable query looks a little weird to me.
SELECT * FROM new org.apache.derby.diag.SpaceTable('APP','CLOBTAB') t
CONGLOMERATENAME
|ISIND&|NUMALLOCATEDPAGES |NUMFREEPAGES |NUMUNFILLEDPAGES
|PAGESIZE |ESTIMSPACESAVING
------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
CLOBTAB
|0 |3 |12 |1
|32768 |393216
SQL090206122912800
|1 |1 |0 |1
|4096 |0
Shouldn't the NUMALLOCATEDPAGES be greater than NUMFREEPAGES + NUMFILLEDPAGES?
> Multithreaded clob update causes growth in table that does not get reclaimed
> ----------------------------------------------------------------------------
>
> Key: DERBY-4050
> URL: https://issues.apache.org/jira/browse/DERBY-4050
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
> Reporter: Kathey Marsden
> Attachments: ClobGrowth.java, derby.log.growth, derby.log.nogrowth
>
>
> Doing a multithreaded update of a Clob table causes table growth that does
> not get reclaimed except by compressing the table. The reproduction has a
> table with two threads. One thread updates row 1 repeatedly with 33,000
> character clob. The other thread updates row 2 with a small clob, "hello".
> The problem occurs back to 10.2 but seems much worse on trunk than 10.2.
> The trunk database grew to 273MB on trunk after 10000 updates of each row.
> The 10.2 database grew only to 25MB. If the update is synchronized there is
> no growth.
> I will attach the repro.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
