db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4376) Simple select runs forever
Date Wed, 16 Sep 2009 11:31:00 GMT

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


Mime
View raw message