Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <748781352.1253023321945.JavaMail.jira@brutus>
Date: Tue, 15 Sep 2009 07:02:01 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4376) Simple select runs forever
In-Reply-To: <798143158.1253004837461.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755499#action_12755499 ] 

Knut Anders Hatlen commented on DERBY-4376:
-------------------------------------------

The next probe value in an IN list (the query in the repro is rewritten to and IN query internally) is fetched by MPTSRS.getNextProbeValue() which is called called by MPTSRS.reopenScanController(). In MPTSRS's parent class (TableScanResultSet) we find this in reopenCore():

		// Check whether there are any comparisons with unordered nulls
		// on either the start or stop position.  If there are, we can
		// (and must) skip the scan, because no rows can qualify
		if (skipScan(startPosition, stopPosition))
		{
			scanControllerOpened = false;
		}
		else
		{
			if (scanController == null)
				openScanController((TransactionController)null);
			else
				reopenScanController();
		
		}

So if startPosition/stopPosition contains a NULL value, reopenScanController() is not called. This means that a new probe value is not fetched, and at the next iteration we'll still be at the same position in the IN list, so we'll just continue trying to reopen the scan with start/stop==NULL again and again.

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