[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436581 ] A B commented on DERBY-1866: ----------------------------
> Does this bug appear in the current 10.1.3 release? Since 10.1.3 doesn't have support for optimizer overrides, I can't run the repro against it to see. I also can't run the original query from DERBY-1777 because the other regressions (esp. DERBY-1633) haven't been fixed in the 10.1.3 release and thus will cause the query to fail before ever reaching the condition for this issue. But even though I can't demonstrate it easily, I'm pretty sure the answer is "Yes". I tried to run the repro script with a set of 10.2 jars that was built before any of the DERBY-805-related changes went in (but after optimizer overrides were added) and the queries pass. So the queries used to work in 10.2 and now they don't--and I'd be very (pleasantly) surprised if the optimizer changes for DERBY-805 weren't somehow responsible. Given that, the 805 changes were ported to 10.1 so I imagine the issue exists in the 10.1.3 release, as well (it's just hidden behind the other regressions that have since been resolved). > 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.2.1.0, 10.1.4.0, 10.1.3.2 > Reporter: A B > Assigned To: A B > Fix For: 10.2.2.0 > > 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 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
