Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <30389380.1158690984521.JavaMail.jira@brutus>
Date: Tue, 19 Sep 2006 11:36:24 -0700 (PDT)
From: "A B (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1866) Assert failure in sane mode for
 queries that used to work in 10.1.2.1
In-Reply-To: <8834277.1158690388278.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]

A B updated DERBY-1866:
-----------------------

    Attachment: derby.log

Attaching a derby.log file that contains the ASSERT failure.  Note that the query in this case is slightly modified from one of the queries in DERBY-1777 (the queries in DERBY-1777 tend to take a very long time to compile; I shortened the query a bit and was still able to see the error).

> 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
>
>
> 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