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] Updated: (DERBY-1866) Assert failure in sane mode for queries that used to work in
Date Thu, 21 Sep 2006 02:13:23 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]

A B updated DERBY-1866:

    Attachment: repro.sql

Quick update on where things are with this issue:

  1. I was (finally) able to come up with a quick and easy repro to 
    demonstrate the ASSERT failure in SANE mode.  I'm attaching 
    a script, repro.sql, that can be run to show the failure.  The repro 
    script also contains another query that is very similar to the first, 
    but the second query appears to hang or otherwise run for a very, 
    very long time, even though it should execute in about a second
     or so.

  2. With the repro attached to this issue, attempts to run in INSANE mode will
     result in an IndexOutOfBounds error--so this issue does not just "go away"
     in insane mode; it is a legitimate regression.

  3. Now the interesting thing: both of the repro queries SUCCEED as expected against
     the 10.1 codeline.  This means that the failures are not part of the initial
     optimizer work (DERBY-805) that went into 10.1, nor are they inherently caused
     by any of the recent optimizer changes that have been ported back to 10.1
     (namely, DERBY-1365, DERBY-1633, DERBY-1681, DERBY-1777, DERBY-1315).

     The repro script passes against the 10.1.3 jars and against a fully-synced
     10.1 codeline.  But it fails against the first 10.2 beta candidate and
     all subsequent candidates; it also fails against the current 10.2 codeline
     and the 10.3 trunk.

     So my natural deduction was that some other optimizer-related change has
     been checked into 10.2 and 10.3 that is not in 10.1, and that's the cause
     of the failure.  But after I applied all such changes (that I could think
     of) to the 10.1 codeline, the repro scripts still pass in 10.1 and fail
     in 10.2/10.3.  The patches I ported to 10.1 (locally) were DERBY-1357,
     DERBY-781, and DERBY-634.  As far as I could tell based on a quick glance
     at the 10.2 release notes, no other optimizer changes were made after the
     10.1.3 release.  I also did a diff of the latest 10.1 trunk with the
     latest 10.3 trunk bewteen the files that have been involved in the
     recent optimizer work, and I couldn't see any diffs that might suggest
     why the repro queries pass for 10.1 but fail for everything else.

I'm still investigating the bizarre behavior for #3.  If anyone offhand can think of any changes
that are in 10.2/10.3 but not in 10.1 that might be responsible for these failures, I'd certainly
appreciate the help.  Right now I'm planning to 1) go back through the release notes for 10.2
more carefully to see if I've missed anything, and 2) make sure all of the patches applied
cleanly when I ported them (locally) to 10.1; maybe something went wrong somewhere...?

In any event, to run the repro, do the following:

> java -Dderby.optimizer.noTimeout=true org.apache.derby.tools.ij
ij> connect 'jdbc:derby:tstdb;create=true';
ij> run 'repro.sql';

Against 10.2 and 10.3 you should see an ASSERT failure for the first query; if you comment
out the first query, you should see an apparent hang for the second query.  But against 10.1,
both queries run successfully and quickly (less than a second).

> 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