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?
If you would write up a release note for this issue, I would be happy to
include it in the 10.2 release notes. Thanks in advance!
I understand your unease here. Our release notes seem to call out the
following issues:
1) New features.
2) Bugs that were fixed.
3) Issues for which someone bothered to demand or write a release note.
Does any product ship in its release notes a comprehensive list of all
known defects? I don't know. I share your misgivings and I'm not
convinced that we've done a very thorough job of identifying issues in
category (3). We could definitely improve our process. If you want to
write notes for any important issues we've missed, I'd be happy to add
them to the release notes.
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?
I see your point. DERBY-1777 doesn't indicate that the defect occurs in
10.1.3. However, I see now that DERBY-1633 and DERBY-1681 do. Perhaps I
should share more of my calculus with you:
A) It is late in the day. To block the release, an issue must be very
serious now.
B) 10.2 isn't any worse than the current release as far as DERBY-1866 is
concerned.
C) The consequences of DERBY-1866 are relatively mild: the query fails,
albeit ungracefully. This bug does not corrupt data and it does not
silently return false results.
I'm happy to hear arguments about why this issue should hold up the release.
Thanks,
-Rick
Thanks for following through with this discussion and making a final decision!
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...
