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 Sun, 24 Sep 2006 23:34:23 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]

A B updated DERBY-1866:

    Attachment: d1866_v1.patch

Attaching a first patch for this issue, d1866_v1.patch.  In short, the problem was that, when
pushing predicates to subqueries beneath UNIONs, the predicates were always being pushed to
the *first* table in the subquery's FROM list, regardless of whether or not that was actually
the correct table.  Thus it was possible to push a predicate down to a base table to which
it didn't apply, thereby leading to an assertion failure in sane mode and an index out of
bounds exception in insane mode.

For details on how this occurred and what the fix is, please refer to the code comments in
the patch.  The d1866_v1 patch does the following:

  1. Adds logic to ensure scoped predicates are only pushed
     to the appropriate base tables.

  2. Adds one line to OptimizerImpl to solve the hang that
     was occuring for the second query shown in repro.sql.
     The problem there was just that one variable was not
     being properly reset when beginning a new round of

  3. Adds some test cases to verify the changes for #1 and

Note that the patch is mostly just explanatory comments for existing and new logic, plus the
test cases.

I ran derbyall on Red Hat Linux with ibm142 using sane jars and there were no new failures.
 I also ran the full ViewerInit program attached to DERBY-1777 and the program ran to completion
without error.  (Note that the queries took a very, very long time to compile, though (longest
one took almost 40 minutes).  Unfortunate though that is, I think that's a separate and more
general issue with Derby optimization of subqueries--one to be addressed further down the

I would appreciate any reviews of this patch--even if it's just a quick read of the code comments
to see if they make sense.  Every little bit helps, and as I'm sure everyone knows by now,
optimizer changes are especially worthy of multiple reviews by as many people as possible...

> 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: d1866_v1.patch, 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