[
https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755984#action_12755984
]
Knut Anders Hatlen commented on DERBY-4376:
-------------------------------------------
Also, TableScanResultSet.reopenCore() will always reset the start key and the
stop key to the first value in the IN list right before we check if the scan
can be skipped. So when the first element in the IN list is NULL, the
start/stop key will always be NULL when skipScan() is called, and skipScan()
will always return true.
For MultiProbeTableScanResultSet I think we need to somehow set the start/stop
key to the actual probe value *before* skipScan() is called.
> Simple select runs forever
> --------------------------
>
> Key: DERBY-4376
> URL: https://issues.apache.org/jira/browse/DERBY-4376
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.4, 10.5.3.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
>
> On Derby 10.3.1.4 and later, I see that evaluating the statements below in ij
> apparently makes Derby go into an infinite loop. The select statement ran for
> two hours until I aborted it. I do not see this problem on Derby 10.2.2.0 or
> earlier.
> ij> create table t(x int primary key);
> 0 rows inserted/updated/deleted
> ij> prepare ps as 'select * from t where x=? or x=?';
> ij> execute ps using 'values (cast(null as int), 0)';
> IJ WARNING: Autocommit may close using result set
> X
> -----------
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
