[
https://issues.apache.org/jira/browse/DERBY-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3538:
-----------------------
Attachment: d3538_notTested.diff
I did some tracing and it *appears* that the problem is in the "doProjection()"
method of ProjectRestrictResultSet. During code generation we recognize that
the SELECT has all constants and thus that its result set is "reusable"; see
ProjectRestrictNode.generateMinion(), esp. the call to:
mb.push(resultColumns.reusableResult());
At execution, ProjectResrictResultSet sees that it can reuse the result set so
it "caches" the execution row in doProjection() and then just returns that on
subsequent calls. However, when returning the cached row, the method does
*not* call "setCurrentRow()" with the cached row. In some cases (esp. left
outer join) that can mean that the "current execution row" corresponding to the
ProjectRestrictResultSet remains null when it should be set to the cached row.
Thus when it comes time to evaluate the ON predicate, which references the
ProjectRestrictResultSet's execution row, the predicate fails with an NPE
because the "current execution row" is not set for that PRRS.
I'm attaching a quick change that resolves the reported NPE. I have *not* run
any tests on this, so it's not for commit (yet). I don't think I'll have much
time to follow-up with this anytime soon, so if anyone out there can pick it up
and take it to completion, that'd be great...
> NullPointerException during execution for query with LEFT OUTER JOIN whose
> inner table selects all constants.
> -------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3538
> URL: https://issues.apache.org/jira/browse/DERBY-3538
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
> Reporter: A B
> Priority: Minor
> Attachments: d3538_notTested.diff
>
>
> For a query having a LEFT OUTER JOIN such that the right, or "inner", table
> is a SELECT subquery whose result column list consists entirely of constants,
> Derby may throw an execution-time NPE while trying to apply the join
> predicate. I say "may" because it depends on which join strategy the
> optimizer chooses.
> Using optimizer overrides I was able to reproduce this problem against trunk
> with the following (admittedly nonsense) query:
> create table t1 (i int, j int);
> insert into t1 values (-1, -2), (-2, -4), (-3, -9);
> select * from
> t1 left outer join
> (select -1 a, 1 b from t1) x0 --DERBY-PROPERTIES joinStrategy=NESTEDLOOP
> on x0.a = t1.i;
> I |J |A |B
> -----------------------------------------------
> -1 |-2 |-1 |1
> -1 |-2 |-1 |1
> -1 |-2 |-1 |1
> ERROR 38000: The exception 'java.lang.NullPointerException' was thrown while
> evaluating an expression.
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> Running the same query also failed with the same NPE on 10.0.2.1, even though
> optimizer overrides don't exist there. So I'm marking all known releases to
> be affected by this issue.
> Note: while this particular query may not make much sense, I have seen a user
> with a very large, auto-generated query that, when executed, fails due to
> this problem. So it is worth investigating...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
