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 Wed, 27 Sep 2006 20:38:02 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438214 ] 
A B commented on DERBY-1866:

Thanks for the review, Yip!

> Can you elaborate on this? In what circumstances where the table number will be -1? 

I think the answer to this question was buried in my earlier reply, namely:

"For a ProjectRestrictNode, if the PRN's child is itself a FromTable (as opposed to, say,
a SelectNode) then the PRN's table number can be -1 and any attempts to "get" the PRN's table
number will return the table number of the PRN's child. If the PRN's child is not a FromTable,
then the PRN will have it's own table number. "

That said, I think the check for "tNum >= 0" in this patch is probably unnecessary, since
in the case just mentioned the call to "getTableNumber()" on a PRN will translate into a call
to "getTableNumber()" on the child, which should then return a non-negative number.  I don't
think it hurts to have the check in there, but since it's not expected to be -1, perhaps I
can post a follow-up patch to remove the check and add an ASSERT to make sure that tNum is
in fact positive...?

> 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