[
https://issues.apache.org/jira/browse/DERBY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528564
]
Bryan Pendleton commented on DERBY-3033:
----------------------------------------
Thanks for the pointer to SubqueryNode.preprocess; we're definitely flattening
this query.
The code goes through the flattenToExistsJoin() path on line 742 of
SubqueryNode.java.
And, to substantiate that more, it's clear from close examination of the data
structures in
the debugger that the overall join tree at execution time is:
(Studies NestedLoop Dispatcher_locks) NestedLoop dicom_send_requests
And at the point of the crash we've:
- fetched the first row from Studies,
- joined it against Dispatcher_locks (discovering that no matching row exists,
so NOT EXISTS is true)
- taken the resulting row and are ready to join it against dicom_send_requests.
I'm wondering if the result set book-keeping gets messed up during flattening.
At the point
that we call getColumnFromRow() to fetch a value from result set 5, it looks to
me like
the information in row[3] is the correct information that we should be
accessing. That is,
when I back up the stack to the NestedLoopJoinResultSet frame, and look at the
value
of "leftRow", which is the row that (I think) should be providing the values
that we are about
to use for the start/stop position computations in the index scan positioning,
the leftRow
instance from that join matches up with row[3] in the BaseActivation generated
instance.
So I'll look at how the result_set numbering is handled during flattening.
> select query results in nullpointer exception in skipScan()
> -----------------------------------------------------------
>
> Key: DERBY-3033
> URL: https://issues.apache.org/jira/browse/DERBY-3033
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Windows XP, Java 5.0, JDBC, Derby 10.2.2.0
> Reporter: Haolan Qin
> Assignee: Bryan Pendleton
> Attachments: bug4736.sql, d3033-sane-ij-session-10.3.1.5.txt,
> query_plan.new, query_plan.old, test.rar, test.zip, viewer_10_1.zip
>
>
> The following error was repeatedly thrown when we tried to run a select query
> via JDBC. Strangely, the exact same select query did not trigger any error
> when run from the command line console. After we added an index, the error
> went away completely.
> java.lang.NullPointerException
> at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.skipScan(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.JoinResultSet.openRight(Unknown Source)
> at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
