Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 16462 invoked from network); 5 Feb 2010 17:37:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Feb 2010 17:37:49 -0000 Received: (qmail 79009 invoked by uid 500); 5 Feb 2010 17:37:49 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 78984 invoked by uid 500); 5 Feb 2010 17:37:49 -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 78976 invoked by uid 99); 5 Feb 2010 17:37:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 17:37:49 +0000 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, 05 Feb 2010 17:37:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id EC51129A0025 for ; Fri, 5 Feb 2010 09:37:27 -0800 (PST) Message-ID: <1174405530.72331265391447966.JavaMail.jira@brutus.apache.org> Date: Fri, 5 Feb 2010 17:37:27 +0000 (UTC) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-4537) Update on tables with blob columns streams blobs into memory even when the blobs are not updated/accessed. In-Reply-To: <700039087.58081265340148283.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830185#action_12830185 ] Mamta A. Satoor commented on DERBY-4537: ---------------------------------------- Yes, here is the stack trace Statement is: update t1 set status = 1 where id = 1 java.lang.OutOfMemoryError at org.apache.derby.impl.store.raw.data.CachedPage.setPageArray(CachedPage.java:864) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:665) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2431) at org.apache.derby.impl.store.raw.data.FileContainer.getNextHeadPage(FileContainer.java:2749) at org.apache.derby.impl.store.raw.data.BaseContainer.getNextPage(BaseContainer.java:516) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.getNextPage(BaseContainerHandle.java:364) at org.apache.derby.impl.store.access.conglomerate.GenericScanController.positionAtNextPage(GenericScanController.java:499) at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(GenericScanController.java:827) at org.apache.derby.impl.store.access.heap.HeapScan.fetchNext(HeapScan.java:238) at org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:577) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:261) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:185) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:127) at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:571) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:254) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1232) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:625) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:521) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:363) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261) at org.apache.derby.impl.tools.ij.Main.go(Main.java:229) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) > Update on tables with blob columns streams blobs into memory even when the blobs are not updated/accessed. > ---------------------------------------------------------------------------------------------------------- > > Key: DERBY-4537 > URL: https://issues.apache.org/jira/browse/DERBY-4537 > Project: Derby > Issue Type: Improvement > Components: SQL > Affects Versions: 10.6.0.0 > Reporter: Mamta A. Satoor > Priority: Minor > Attachments: derby4537Repro.java > > > While investigating DERBY-1482, I wrote a simple program to see the behavior of a simple update (without any triggers) of a table with blob columns. > The update is on a non-blob column of a table with blob volumns. > When this update is made with limited heap memory, Derby runs into OOM error. > I tried another table similar to earlier table but with no blob column. An update on that table does not run into OOM when run with same limited heap memory. > I would have expected the update to pass for table with blob column since we are not referencing/updating the blob column. But it appears that we might be streaming in blob column even though it is untouched by the update sql. > I wonder if working on this jira first will make the work for DERBY-1482 any easier or better yet, will it make the problem with DERBY-1482 go away? Will attach a reproducible program for this soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.