[ 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 10.1.2.1 > --------------------------------------------------------------------- > > Key: DERBY-1866 > URL: http://issues.apache.org/jira/browse/DERBY-1866 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.1.3.2, 10.1.4.0, 10.2.1.5 > Reporter: A B > Assigned To: A B > Fix For: 10.2.2.0, 10.3.0.0 > > 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 failures. > 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 10.2.2.0 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
