db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3538) NullPointerException during execution for query with LEFT OUTER JOIN whose inner table selects all constants.
Date Fri, 14 Mar 2008 05:37:24 GMT

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


Mime
View raw message