db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-1866) Assert failure in sane mode for queries that used to work in
Date Thu, 21 Sep 2006 21:38:18 GMT
In my opinion we are ready to make a release candidate.  I was out 
during the recent license workaround discussion.  I think the proposed
workaround is reasonable and it is about time to get this release out.
At this point I don't think there are easy hard/fast rules.  In your 
example maybe we would hold back because there was a large number of
such issues, vs. 1.

I agree with rick that I would not hold up 10.2 release for a reported 
and as yet unfixed bug  for an existing
issue in 10.1.3, even if it worked in 10.1.2. If there was an existing
patch to fix, then I might consider it.

But at this point it is all about weighing the value to users who have 
been waiting a long time for 10.2 vs. delaying for "one last bug".  At 
this point it would take a very serious regression for me to think we
should hold up - something like a db corruption regression.  I think it
would even be ok to go out with less serious regressions, documenting 
what they are and making them high priority for gettting them fixed in
the branch ASAP.  This is opensource, once they are in the branch anyone
who cares enough can get it immediately.

With this specific bug I think the "good" news (for some twisted 
definition of "good"), is that a user running into the problem will know 
it as they will get an error of some kind (vs. a wrong result). 
Hopefully this will lead them to the DERBY-1866 discussion of the 
outstanding issue.

I do think that at this point we should get all the relevant patches in
the trunk merged into the 10.2 branch, and committers should take a 
careful look at outstanding patches to make sure all that make sense
are in 10.2.

A B (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436637 ]

> A B commented on DERBY-1866:
> ----------------------------
>>As I understand it, this bug exists in the 10.1.3 release. It seems that, as far as
this bug is
>>concerned, 10.2 is no worse than 10.1.3. For that reason, I would not be inclined
to hold up
>>the 10.2 release for this bug fix.
> Two things:
>   1. Are we going to mention the known issues (esp. regressions) that exist with the
10.2 release (aside from intentional behavioral changes) somewhere in the release notes? 
I looked at the html file attached to DERBY-1860 and didn't see any (the "issues" section
just holds release notes for intentional behavior changes and/or fixes).  Are we just leaving
it up to the users to navigate Jira to find outstanding issues like DERBY-1866?
>   2. Just as a note, this reasoning for not holding up the release also applies to DERBY-1777,
DERBY-1633, and DERBY-1681, since all of those fail with 10.1.3 release, as well.  (Oh, and
*DERBY-1854*, for that matter!)  Am I to understand that if any of those was still unresolved,
we'd go ahead with the release nonetheless?  I'm not disagreeing with the decision, just curious
if the "it's no worse than <previous release>" rule is specific to this particular Jira
or if it applies on a more general scale?
> Thanks for following through with this discussion and making a final decision!
>>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: 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...

View raw message