You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2006/09/19 20:26:28 UTC
[jira] Created: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
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.0
Reporter: A B
Assigned To: A B
Fix For: 10.2.2.0
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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Yip Ng (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438215 ]
Yip Ng commented on DERBY-1866:
-------------------------------
Right. You mentioned one case where this can be -1 on your earlier reply, but I was wondering if there are any other cases where table number can be -1 since you mentioned there are some cases. I think the extra check for tNum >= 0 is fine as is.
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436572 ]
Rick Hillegas commented on DERBY-1866:
--------------------------------------
Thanks for the quick response, Army. Does this bug appear in the current 10.1.3 release?
> 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
Re: [jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by Army <qo...@gmail.com>.
Rick Hillegas wrote:
> 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:
<snip all very good points>
> I'm happy to hear arguments about why this issue should hold up the
> release.
No, no arguments at all. Sorry if it sounded like I was looking for a reversal
of your decision. I wasn't debating the decision, just looking for
clarification about 1) why 1866 didn't make the cut but the others did, and 2)
how (or if) we make the user-base aware of the regression.
I think you've answered both of those questions--so thanks!
Carry on, carry on...
Army
Re: Including known problems in the release notes
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> Does any product ship in its release notes a comprehensive list of all
> known defects?
It seems to me that is provided by: http://issues.apache.org/jira/browse/DERBY
I don't see much value in duplicating that information into a separate doc.
I think it is better to concentrate on making the information in JIRA
solid and useful, and encourage people who want to know about problems
to search JIRA and consult the information there.
thanks,
bryan
Re: [jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by Rick Hillegas <Ri...@Sun.COM>.
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...
>>
>>
>
>
>
Re: [jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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 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...
>
>
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Yip Ng (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438200 ]
Yip Ng commented on DERBY-1866:
-------------------------------
Hi Army, I read through the patch and the changes seem reasonable to me.
You mentioned that:
"all FromTables (aka "Optimizables") in the entire query will have an assigned table number (if required--in some cases it's not necessary and thus will be -1)."
Can you elaborate on this? In what circumstances where the table number will be -1?
tNum = ((FromTable)curTable).getTableNumber();
...
if (tNum >= 0)
curTableNums.set(tNum);
> 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.5, 10.1.4.0, 10.1.3.2
> Reporter: A B
> Assigned To: A B
> Fix For: 10.3.0.0, 10.2.2.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
[jira] Resolved: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
Andrew McIntyre resolved DERBY-1866.
------------------------------------
Resolution: Fixed
Derby Info: [Regression] (was: [Patch Available, Regression])
> 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.1.4.0, 10.2.1.5, 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
Rick Hillegas updated DERBY-1866:
---------------------------------
Fix Version/s: 10.2.1.5
(was: 10.2.2.0)
(was: 10.3.0.0)
Looks like this one made it into 10.2.1.
> 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.1.5
>
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438165 ]
A B commented on DERBY-1866:
----------------------------
Hi Bryan, thanks for looking at the patch and for being willing to ask some good questions. Below are my (perhaps slightly lengthy) responses. If this doesn't address your questions or leaves you with new questions, please don't hesitate to ask again...
Thanks,
Army
----
Q1: At this point in the processing, have constructs like views
and synonyms already been transformed and replaced by their
underlying "real" tables?
Yes. Transformations and table resolution occur during the "binding" and "preprocessing" stages of query compilation--and both of those stages occur before optimization begins. So at this point a view will be represented by a ProjectRestrictNode whose child is a SelectNode, and a synonym will be represented by whatever FromTable it (the synonym) is actually referring to.
Table numbers are also assigned during binding/preprocessing, so by the time we get to the code in d1866_v1.patch, all FromTables (aka "Optimizables") in the entire query will have an assigned table number (if required--in some cases it's not necessary and thus will be -1). Additionally any column reference which points to one of those FromTables will have the table number for that FromTable stored locally (namely, in ColumnReference.tableNumber).
Note that when a ColumnReference is "remapped" to point to a different FromTable, its local information--including tableNumber--is updated accordingly. Note also that a "FromTable" is not restricted to base tables--anything that can be specified in the FROM list of a SELECT query will be represented by some instance of FromTable, whether it be a subquery, a base table, a union node, etc. Every FromTable has its own "table number", with the exception of ProjectRestrictNodes. For a PRN, if the PRN's child is itself a FromTable (as opposed to, say, a SelectNode) then the PRN's table number will 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.
Q2: If the optimizer is choosing to access an index for a table, rather
than accessing the table itself, does the table number change depending
on whether it is an index or a base table which is being processed
by the ProjectRestrictNode?
Great question. Short answer is "no" :)
The thing to note here is that "table number" is strictly a language-created, compilation time value to allow binding, preprocessing, optimization, and code generation to distinguish between the various FromTables in the original query. A table number is not stored on disk and it is independent of the access path decisions (including whether or not an index is used) made by the optimizer. Furthermore, there is no link between a given table number and the actual on-disk table that it points to. Table number 0 could be for T1 in one query, T2 in another query, and T100 in a third query.
As a simple (but admittedly meaningless) example, take the following query:
select t1.i, x1.j from t1, t1 x1 where t1.i = x1.j;
At bind time Derby will assign every item in the FROM list a table number. So in this case, "T1" gets table number 0 and "T1 X1" gets table number 1. The fact that both FromTables are really pointing to the same base table doesn't matter. For the duration of compilation/optimization, they are represented by two different instances of FromTable and are considered two different "tables", each having its own table number. (For the record, in this particular example the different FromTables will in fact point to the same underlying tableDescriptor field).
Given that, the predicate "t1.i = x1.j" will have a left ColumnReference pointing to a FromBaseTable representing T1 with table number "0" and a right ColumnReference pointing to a different FromBaseTable representing X1 (i.e. T1 again) with table number "1".
If the optimizer then decides to use an index for T1, the table number doesn't change--the optimizer just decides that for "the FromBaseTable whose table number is 0 we will use an index". In fact, once assigned, the table number for a specific FromTable remains the same for the duration of the compilation of the statement.
That was a round-about way of getting to the answer, but hopefully that's more helpful than confusing...
As I said, if you still have questions/confusion, please do ask again. It's always good to answer questions like these, as it makes me re-check what I think I "know" and forces me to verify my replies by looking at the code again...
> 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.5, 10.1.4.0, 10.1.3.2
> Reporter: A B
> Assigned To: A B
> Fix For: 10.3.0.0, 10.2.2.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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Yip Ng (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438534 ]
Yip Ng commented on DERBY-1866:
-------------------------------
Yes, that is what I was looking for. Thanks for the extensive analysis and explanation on the table number logic in the optimizer, Army.
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436630 ]
Rick Hillegas commented on DERBY-1866:
--------------------------------------
Thanks, Army. 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.
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438001 ]
Bryan Pendleton commented on DERBY-1866:
----------------------------------------
Hi Army, I read through your code and tests; thanks for the clear and detailed comments!
I noticed that the crucial bit of the change had to do with a comparison of table numbers;
I'm not real familiar with how table numbers work, so I thought I'd ask a pretty naive question:
at this point in the processing, have constructs like views and synonyms already been
transformed and replaced by their underlying "real" tables?
Also, and related:
If the optimizer is choosing to access an index for a table, rather than accessing the
table itself, does the table number change depending on whether it is an index or
a base table which is being processed by the ProjectRestrictNode?
> 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.5, 10.1.4.0, 10.1.3.2
> 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
[jira] Closed: (DERBY-1866) Assert failure in sane mode for queries
that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
A B closed DERBY-1866.
----------------------
Fix is in 10.3, 10.2, and 10.1, and I haven't heard any follow-up feedback, so marking is as closed.
> 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.6
> Reporter: A B
> Assigned To: A B
> Fix For: 10.2.1.6, 10.1.4.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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436569 ]
A B commented on DERBY-1866:
----------------------------
> 1) What happens if you run the repro against an insane (e.g., production-ready) 10.2?
The result is an IndexOutOfBoundsException at execution time:
ERROR 38000: The exception 'java.lang.ArrayIndexOutOfBoundsException: -1' was thrown while evaluating an expression.
> 2) I'm confused about whether this is a regression.
Good question, sorry for not being clear here. This is a regression in the same way that DERBY-1633, DERBY-1781, etc. are regressions: namely, queries used to work correctly at one point in 10.2, but then as a result of optimizer changes (esp. DERBY-805) they no longer work. As it turns out, DERBY-805 was also ported back to 10.1.2.4 and thus the regressions also occur in the recent 10.1 codeline/release. That's why the changes for DERBY-1633, DERBY-1681, DERBY-1777, and DERBY-1315 have all been ported back to 10.1.
So if you define "regression" as "worked in the latest 10.1 release but fails in 10.2", then neither this nor any of the other issues were technically "regressions" for 10.2--because they all demonstrate bugs that exist in 10.1.3 and 10.2 alike. But the truth is that the queries *did* work in 10.1 and they *did* work in 10.2 before the DERBY-805 changes went in, and now they don't work in either.
> then the bug would surface in 10.1 as well. From your description, this seems like a
> pre-existing bug which we are now able to script and (eventually) fix because of
> optimizer overrides.
Yes, "pre-existing" in 10.1 because the code that caused the regression was (unfortunately) ported back to 10.1, as well...
I can't seem to put it in the right words, but hopefully that makes more sense...?
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
A B updated DERBY-1866:
-----------------------
Attachment: d1866_v1.patch
Attaching a first patch for this issue, d1866_v1.patch. In short, the problem was that, when pushing predicates to subqueries beneath UNIONs, the predicates were always being pushed to the *first* table in the subquery's FROM list, regardless of whether or not that was actually the correct table. Thus it was possible to push a predicate down to a base table to which it didn't apply, thereby leading to an assertion failure in sane mode and an index out of bounds exception in insane mode.
For details on how this occurred and what the fix is, please refer to the code comments in the patch. The d1866_v1 patch does the following:
1. Adds logic to ensure scoped predicates are only pushed
to the appropriate base tables.
2. Adds one line to OptimizerImpl to solve the hang that
was occuring for the second query shown in repro.sql.
The problem there was just that one variable was not
being properly reset when beginning a new round of
optimization.
3. Adds some test cases to verify the changes for #1 and
#2.
Note that the patch is mostly just explanatory comments for existing and new logic, plus the test cases.
I ran derbyall on Red Hat Linux with ibm142 using sane jars and there were no new failures. I also ran the full ViewerInit program attached to DERBY-1777 and the program ran to completion without error. (Note that the queries took a very, very long time to compile, though (longest one took almost 40 minutes). Unfortunate though that is, I think that's a separate and more general issue with Derby optimization of subqueries--one to be addressed further down the road...)
I would appreciate any reviews of this patch--even if it's just a quick read of the code comments to see if they make sense. Every little bit helps, and as I'm sure everyone knows by now, optimizer changes are especially worthy of multiple reviews by as many people as possible...
> 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.4, 10.1.4.0, 10.1.3.2
> Reporter: A B
> Assigned To: A B
> Fix For: 10.2.2.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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436522 ]
A B commented on DERBY-1866:
----------------------------
Okay, forget about #3 above:
After a night's sleep it occurred to me why the repro "passes" in 10.1 but not in 10.2 or 10.3. The reason is that the repro relies on behavior dictated by optimizer overrides (DERBY-PROPERTIES), but such overrides are not recognized in 10.1 and thus they are treated as SQL comments and are ignored.
I haven't tried it yet, but I imagine that if I ported the optimizer overrides patch to 10.1, the repro would fail there; similarly, if I remove the optimizer overrides from the repro queries, they will probably pass in 10.2 and 10.3.
So short story: we do have a legitimate regression, and now that we have a repro, I'm working to find the problem...
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438527 ]
A B commented on DERBY-1866:
----------------------------
> You mentioned one case where this can be -1 on your earlier reply,
> but I was wondering if there are any other cases where table number
> can be -1 since you mentioned there are some cases.
Sorry for misunderstanding your question. When I wrote "some" cases I intended that to mean that there are "some" cases where a ProjectRestrictNode (PRN)'s tableNumber can be -1 (namely, if it's child is an Optimizable). Since that's the only time I've ever seen a negative table number when tracing through code, I've been assuming that's the only case when it can happen.
But inspired by your question, I decided to do a search through the codeline to see if there are any other situations when a table number can be -1 during optimization. (Note: the emphasis here is on optimization, since that's the area of code at issue with this Jira).
The only other case I found was for NormalizeResultSetNode, which is created for InsertNode and UpdateNode. But NormalizeResultSetNodes are generated on top of a ResultSetNode to be optimized--they are not themselves optimized, which means that we wouldn't ever get to the code in d1866_v1.patch with a "curTable" that is a NormalizeResultSetNode. So even though a NormalizeRSN can have a negative table number, that doesn't affect the proposed changes.
Thus based on my understanding, the only time a FromTable's table number can be -1 during optimization is if it is in fact a ProjectRestrictNode with a non-FromTable subquery as its child.
As a minor sort of sanity check for these results, I put a System.out in OptimizerImpl to print a message if we ever saw an Optimizable that had a negative table number but that was not a PRN, and then I ran derbylang. The message was never printed. This doesn't "prove" anything in particular, but it does lend evidence to the results of my code search...
---
Details on my search:
Below are the classes I found that extend FromTable. I looked to see 1) where the various classes were instantiated, and 2) where their table numbers were set (if at all). The breakdown based on my searching is as follows:
FromTables whose table numbers are always set during binding (and thus will not be -1 when it comes time to optimize):
CurrentOfNode
FromBaseTable
FromSubquery
FromVTI
RowResultSetNode
TableOperatorNode
->JoinNode (via inheritance from TableOp)
--->HalfOuterJoinNode (inheritance from TableOp)
->SetOperatorNode (inheritance from TableOp)
--->IntersectOrExceptNode (inheritance from TableOp)
--->UnionNode (inheritance from TableOp)
FromTables that are only instantiated AFTER optimization has completed, and thus even though their table numbers can be -1, that won't affect optimization.
IndexToBaseRowNode
SingleChildResultSetNode
->DistinctNode
->GroupByNode
->HashTableNode
->MaterializeResultSetNode
->OrderByNode
->ScrollInsensitiveResultSetNode
FromTables that can be instantiated during preprocessing but that may not have their table numbers set (these are the ones of interest to the current discussion):
ProjectRestrictNode:
If created during preprocessing, table number will only be set in
FromSubquery.extractSubquery(); in all other cases it will remain -1.
NormalizeResultSetNode:
Instantiated during bind phase for InsertNode and UpdateNode
but table number is not set. So it will be -1. However,
a NormalizeresultSetNode never appears in an optimizer's
optimizableList, and thus such a node will never actually
be optimized.
----
Hopefully that's more in line with what you were asking?
Thanks again for the review and great questions...
> 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
Mike Matrigali updated DERBY-1866:
----------------------------------
Fix Version/s: 10.1.4.0
10.3.0.0
I backported this fix to both the 10.2 and 10.1 branches.
> 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.1.5, 10.1.4.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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436559 ]
Rick Hillegas commented on DERBY-1866:
--------------------------------------
Thanks for looking into this, Army. I have a couple comments:
1) What happens if you run the repro against an insane (e.g., production-ready) 10.2?
2) I'm confused about whether this is a regression. It sound as though, if you could force the query plan in 10.1 (as you can in 10.2), then the bug would surface in 10.1 as well. From your description, this seems like a pre-existing bug which we are now able to script and (eventually) fix because of optimizer overrides.
> 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
[jira] Commented: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
A B updated DERBY-1866:
-----------------------
Fix Version/s: 10.3.0.0
Derby Info: [Patch Available, Regression] (was: [Regression])
> 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.5, 10.1.4.0, 10.1.3.2
> Reporter: A B
> Assigned To: A B
> Fix For: 10.3.0.0, 10.2.2.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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
A B updated DERBY-1866:
-----------------------
Attachment: repro.sql
Quick update on where things are with this issue:
1. I was (finally) able to come up with a quick and easy repro to
demonstrate the ASSERT failure in SANE mode. I'm attaching
a script, repro.sql, that can be run to show the failure. The repro
script also contains another query that is very similar to the first,
but the second query appears to hang or otherwise run for a very,
very long time, even though it should execute in about a second
or so.
2. With the repro attached to this issue, attempts to run in INSANE mode will
result in an IndexOutOfBounds error--so this issue does not just "go away"
in insane mode; it is a legitimate regression.
3. Now the interesting thing: both of the repro queries SUCCEED as expected against
the 10.1 codeline. This means that the failures are not part of the initial
optimizer work (DERBY-805) that went into 10.1, nor are they inherently caused
by any of the recent optimizer changes that have been ported back to 10.1
(namely, DERBY-1365, DERBY-1633, DERBY-1681, DERBY-1777, DERBY-1315).
The repro script passes against the 10.1.3 jars and against a fully-synced
10.1 codeline. But it fails against the first 10.2 beta candidate and
all subsequent candidates; it also fails against the current 10.2 codeline
and the 10.3 trunk.
So my natural deduction was that some other optimizer-related change has
been checked into 10.2 and 10.3 that is not in 10.1, and that's the cause
of the failure. But after I applied all such changes (that I could think
of) to the 10.1 codeline, the repro scripts still pass in 10.1 and fail
in 10.2/10.3. The patches I ported to 10.1 (locally) were DERBY-1357,
DERBY-781, and DERBY-634. As far as I could tell based on a quick glance
at the 10.2 release notes, no other optimizer changes were made after the
10.1.3 release. I also did a diff of the latest 10.1 trunk with the
latest 10.3 trunk bewteen the files that have been involved in the
recent optimizer work, and I couldn't see any diffs that might suggest
why the repro queries pass for 10.1 but fail for everything else.
I'm still investigating the bizarre behavior for #3. If anyone offhand can think of any changes that are in 10.2/10.3 but not in 10.1 that might be responsible for these failures, I'd certainly appreciate the help. Right now I'm planning to 1) go back through the release notes for 10.2 more carefully to see if I've missed anything, and 2) make sure all of the patches applied cleanly when I ported them (locally) to 10.1; maybe something went wrong somewhere...?
In any event, to run the repro, do the following:
> java -Dderby.optimizer.noTimeout=true org.apache.derby.tools.ij
ij> connect 'jdbc:derby:tstdb;create=true';
ij> run 'repro.sql';
Against 10.2 and 10.3 you should see an ASSERT failure for the first query; if you comment out the first query, you should see an apparent hang for the second query. But against 10.1, both queries run successfully and quickly (less than a second).
> 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1866?page=all ]
Mike Matrigali updated DERBY-1866:
----------------------------------
I ran a success full set of tests against this patch against windows XP and ibm 1.4.2. jvm. I reviewed the changes and the extensive comments seemed to match up with what the code was doing. Looked like good tests were being added for the problem. I am no optimizer expert so I suggest at least one more reviewer before we consider moving this patch from the trunk to 10.2 codeline. Am committing this to the trunk to get it more testing.
If possible it would be good if anyone dependent on this change can test out the fix in the trunk and verify it works for
them.
I committed this to the trunk:
m1_ibm142:5>svn commit
Sending java\engine\org\apache\derby\impl\sql\compile\OptimizerImpl.java
Sending java\testing\org\apache\derbyTesting\functionTests\master\predicatePushdown.out
Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\predicatePushdown.sql
Transmitting file data ...
Committed revision 450155.
> 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
[jira] Updated: (DERBY-1866) Assert failure in sane mode for
queries that used to work in 10.1.2.1
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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