NullPointerException during execution for query with LEFT OUTER JOIN whose inner table selects all constants.

• Key: DERBY-3538
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Minor
• Assignee: A B
• Reporter: A B
• Component/s: SQL
• Affects Version/s: 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
• Fix Version/s: 10.1.3.2, 10.2.2.1, 10.3.3.0, 10.4.1.3, 10.5.1.1

Description

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

Comments

[A B]

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

[Thomas Nielsen]

Patch, comments and explaination is very good.

Running some tests on it now.

[Kathey Marsden]

Here is the patch with a test added. I ran suites.All and derbyall with Army's patch and all passed. Thomas if you have not seen any issues with the patch I would like to commit and start backporting back to 10.4,3,2 &1.

[Kathey Marsden]

Committed fix and ported to 10.4,10.3,10.2, and 10.1

[Thomas Nielsen]

Sorry for the very late reply. Just for the record I saw no problems with the patch applied.