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] Commented: (DERBY-1866) Assert failure in sane mode for queries that used to work in
Date Thu, 21 Sep 2006 16:04:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436569 ] 
A B commented on DERBY-1866:

> 1) What happens if you run the repro against an insane (e.g., production-ready) 10.2?

The result is an IndexOutOfBoundsException at execution time:

ERROR 38000: The exception 'java.lang.ArrayIndexOutOfBoundsException: -1' was thrown while
evaluating an expression.

> 2) I'm confused about whether this is a regression.

Good question, sorry for not being clear here.  This is a regression in the same way that
DERBY-1633, DERBY-1781, etc. are regressions: namely, queries used to work correctly at one
point in 10.2, but then as a result of optimizer changes (esp. DERBY-805) they no longer work.
 As it turns out, DERBY-805 was also ported back to and thus the regressions also
occur in the recent 10.1 codeline/release.  That's why the changes for DERBY-1633, DERBY-1681,
DERBY-1777, and DERBY-1315 have all been ported back to 10.1.

So if you define "regression" as "worked in the latest 10.1 release but fails in 10.2", then
neither this nor any of the other issues were technically "regressions" for 10.2--because
they all demonstrate bugs that exist in 10.1.3 and 10.2 alike.  But the truth is that the
queries *did* work in 10.1 and they *did* work in 10.2 before the DERBY-805 changes went in,
and now they don't work in either.

> then the bug would surface in 10.1 as well. From your description, this seems like a

> pre-existing bug which we are now able to script and (eventually) fix because of
> optimizer overrides.

Yes, "pre-existing" in 10.1 because the code that caused the regression was (unfortunately)
ported back to 10.1, as well...

I can't seem to put it in the right words, but hopefully that makes more sense...?

> Assert failure in sane mode for queries that used to work in
> ---------------------------------------------------------------------
>                 Key: DERBY-1866
>                 URL: http://issues.apache.org/jira/browse/DERBY-1866
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,,
>            Reporter: A B
>         Assigned To: A B
>             Fix For:
>         Attachments: derby.log, repro.sql
> Derby-1777 gives a database and a small program called "ViewerInit" that prepares a bunch
of large queries involving nested subqueries, unions, and join predicates.  The actual bug
described in DERBY-1777 is an NPE, and that's what the patch for DERBY-1777 addresses.
> However, once the NPEs are fixed, some of the queries in that same program now fail with
ASSERT failures when running in SANE mode; this Jira issue is for addressing those assert
> While this does constitute a regression, I don't know yet what the root cause of the
problem is, so I hesitate to make it a 10.2 blocker--hence urgency is "Normal".  I'm still
investigating the queries to try to track down where the problem is, but all I've been able
to deduce so far is that a) the assertion occurs for a scoped predicate and thus the pushing
of join predicates into UNIONs is somehow involved, and b) in INSANE mode the query compiles
without problem and appears (based on some early and very incomplete testing) to execute without
problem.  But more investigation is required to determine if the execution/results are actually
correct, and to understand more about why the assertion is being thrown.
> I'm marking the fixin as for now since I don't enough to make this a blocker
for 10.2.1.  Hopefully more info will be forthcoming...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message