[
https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755985#action_12755985
]
Knut Anders Hatlen commented on DERBY-4376:
-------------------------------------------
Forgot to mention that initializing start/stop key to the first value in the IN
list is documented in PredicateList (see the comment below). Anyway, since it's
just a placeholder, it is not correct to use that value as the argument to
skipScan().
/* If we have a "useful" IN list probe predicate we will
generate a
* start/stop key for optTable of the form "col = <val>", where
<val>
* is the first value in the IN-list. Then during normal index
multi-
* probing (esp. as implemented by
exec/MultiProbeTableScanResultSet)
* we will use that start/stop key as a "placeholder" into
which we'll
* plug the values from the IN-list one at a time.
> 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.
