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, 28 Sep 2006 19:03:52 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438527 ] 
A B commented on DERBY-1866:

> You mentioned one case where this can be -1 on your earlier reply,
> but I was wondering if there are any other cases where table number
> can be -1 since you mentioned there are some cases.

Sorry for misunderstanding your question.  When I wrote "some" cases I intended that to mean
that there are "some" cases where a ProjectRestrictNode (PRN)'s tableNumber can be -1 (namely,
if it's child is an Optimizable).  Since that's the only time I've ever seen a negative table
number when tracing through code, I've been assuming that's the only case when it can happen.

But inspired by your question, I decided to do a search through the codeline to see if there
are any other situations when a table number can be -1 during optimization.  (Note: the emphasis
here is on optimization, since that's the area of code at issue with this Jira).

The only other case I found was for NormalizeResultSetNode, which is created for InsertNode
and UpdateNode.  But NormalizeResultSetNodes are generated on top of a ResultSetNode to be
optimized--they are not themselves optimized, which means that we wouldn't ever get to the
code in d1866_v1.patch with a "curTable" that is a NormalizeResultSetNode.  So even though
a NormalizeRSN can have a negative table number, that doesn't affect the proposed changes.

Thus based on my understanding, the only time a FromTable's table number can be -1 during
optimization is if it is in fact a ProjectRestrictNode with a non-FromTable subquery as its

As a minor sort of sanity check for these results, I put a System.out in OptimizerImpl to
print a message if we ever saw an Optimizable that had a negative table number but that was
not a PRN, and then I ran derbylang.  The message was never printed.  This doesn't "prove"
anything in particular, but it does lend evidence to the results of my code search...


Details on my search:

Below are the classes I found that extend FromTable.  I looked to see 1) where the various
classes were instantiated, and 2) where their table numbers were set (if at all).  The breakdown
based on my searching is as follows:

FromTables whose table numbers are always set during binding (and thus will not be -1 when
it comes time to optimize):

 ->JoinNode (via inheritance from TableOp)
 --->HalfOuterJoinNode (inheritance from TableOp)
 ->SetOperatorNode (inheritance from TableOp)
 --->IntersectOrExceptNode (inheritance from TableOp)
 --->UnionNode (inheritance from TableOp)

FromTables that are only instantiated AFTER optimization has completed, and thus even though
their table numbers can be -1, that won't affect optimization.


FromTables that can be instantiated during preprocessing but that may not have their table
numbers set (these are the ones of interest to the current discussion):


  If created during preprocessing, table number will only be set in
  FromSubquery.extractSubquery(); in all other cases it will remain -1.


  Instantiated during bind phase for InsertNode and UpdateNode
  but table number is not set.  So it will be -1.  However,
  a NormalizeresultSetNode never appears in an optimizer's
  optimizableList, and thus such a node will never actually
  be optimized.


Hopefully that's more in line with what you were asking?

Thanks again for the review and great questions...

> 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