db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Resolved: (DERBY-1329) ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.
Date Thu, 08 Jun 2006 20:57:32 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1329?page=all ]
A B resolved DERBY-1329:

    Resolution: Fixed

Checked into trunk with svn # 411393 and into 10.1 with svn # 412832.  I have verified the
fix in both codelines by running the repro and by running the new test case in lang/update.sql,
so I'm resolving and closingt the issue.  Thank you for committing, Satheesh.

> ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET
... WHERE CURRENT OF ... statement.
> ------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1329
>          URL: http://issues.apache.org/jira/browse/DERBY-1329
>      Project: Derby
>         Type: Bug

>   Components: SQL
>     Versions:,,,,,,,,,,
>     Reporter: A B
>     Assignee: A B
>     Priority: Minor
>      Fix For:,
>  Attachments: d1329.java, d1329.patch, d1329_10_1.patch
> If in a statement of the form "UPDATE ... SET ... WHERE CURRENT OF ..." the SET clause
includes a correlated subquery that has a predicate referencing the table that is being updated,
Derby will fail with an ASSERT failure in sane mode and an IndexOutOfBounds exception in insane
> For example, if we have a cursor CUR1 for the results of a SELECT query on BASICTABLE1,
and then we try to execute the following update statement:
> update BASICTABLE1 set C3 = (SELECT CC3 FROM
> where current of CUR1
> the result in SANE mode will be:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED tableNumber is expected
to be non-negative.
> and in INSANE mode will be:
> java.lang.IndexOutOfBoundsException: bitIndex < 0: -1
> The failure occurs during preprocessing of the subquery node when Derby is trying to
"categorize" a predicate to see if it is pushable.  The exact code is in ColumnReference.categorize():
>   public boolean categorize(JBitSet referencedTabs, boolean simplePredsOnly)
>   {
>     if (SanityManager.DEBUG)
>       SanityManager.ASSERT(tableNumber >= 0,
>          "tableNumber is expected to be non-negative");
>     referencedTabs.set(tableNumber);
>     return ( ! replacesAggregate ) &&
>         ( (source.getExpression() instanceof ColumnReference) ||
>         (source.getExpression() instanceof VirtualColumnNode) ||
>         (source.getExpression() instanceof ConstantNode));
>   }
> We get to this code for a ColumnReference who's tableNumber is -1, which means that,
in sane mode, the assert will fire; in insane mode, we'll call "referencedTabs.set()" passing
in a -1, which leads to the IndexOutOfBoundsException.
> This failure occurs in embedded and with both clients, and occurs in 10.0, 10.1, and
the 10.2 trunk.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message