Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 59850 invoked from network); 6 Feb 2009 20:37:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Feb 2009 20:37:23 -0000 Received: (qmail 20928 invoked by uid 500); 6 Feb 2009 20:37:22 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 20898 invoked by uid 500); 6 Feb 2009 20:37:22 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 20889 invoked by uid 99); 6 Feb 2009 20:37:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Feb 2009 12:37:22 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Feb 2009 20:37:20 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 975B4234C4AB for ; Fri, 6 Feb 2009 12:36:59 -0800 (PST) Message-ID: <1768960201.1233952619618.JavaMail.jira@brutus> Date: Fri, 6 Feb 2009 12:36:59 -0800 (PST) From: "Kathey Marsden (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-4050) Multithreaded clob update causes growth in table that does not get reclaimed In-Reply-To: <1476477017.1233881639670.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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.