You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2009/09/15 10:53:57 UTC
[jira] Created: (DERBY-4376) Simple select runs forever
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.5.3.0, 10.3.1.4, 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.
[jira] Updated: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4376:
--------------------------------------
Attachment: derby-4376-1a.stat
derby-4376-1a.diff
Here's a patch with a fix for this issue, and with a test case.
The patch moves all the multi-probe logic out of TableScanResultSet and into MultiProbeTableScanResultSet, and instead created methods that MPTSRS could override where different logic was needed. In short:
1) Initialization of the start/stop keys has been factored out of TSRS.openCore()/TSRS.reopenCore() into a helper method initStartAndStopKey().
2) MPTSRS overrides initStartAndStopKey() and updates the keys with the actual probe value. This ensures that the keys now have the correct values when TSRS.reopenCore() calls skipScan().
3) Methods in TSRS that take a probeValue argument have been removed, since MPTSRS.initStartAndStopKey() now does all the work with retrieving the probe value and updating the keys.
4) Since the next probe value is fetched earlier now MPTSRS.reopenScanController() can no longer use the return value from getNextProbeValue() to decide whether or not it should be a no-op (it should be a no-op the next probe value was null, which means that the probe list has been exhausted). To ensure that we don't open scans in those cases, set a flag in initStartAndStopKey() to indicate whether or not the probe list was exhausted, and override skipScan() to check that flag and return true if no new probe value was found.
(As a side note to 4, this should only happen when the last element in the probe list is equal to the previous element. I cannot see that this special case is tested by InListMultiProbeTest. Looking at Ole's weekly test coverage report, it looks like the code that handles duplicate values in the probe list is not exercised at all by our current tests. I will add some test cases to exercise those code paths, but in a separate patch/issue since it's not directly related to this bug.)
I've started a full run of the regression test suites.
> 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
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Closed: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen closed DERBY-4376.
-------------------------------------
Resolution: Fixed
Fix Version/s: 10.5.3.1
Merged the fix to the 10.5 branch and committed revision 818924.
> 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
> Fix For: 10.5.3.1, 10.6.0.0
>
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755424#action_12755424 ]
Knut Anders Hatlen commented on DERBY-4376:
-------------------------------------------
The query uses a MultiProbeTableScanResultSet, which was introduced in 10.4.1.3 as part of DERBY-47.
> 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.
[jira] Updated: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4376:
--------------------------------------
Issue & fix info: [Repro attached] (was: [Repro attached, Patch Available])
Fix Version/s: 10.6.0.0
Committed revision 816536.
I plan to port the fix to the 10.5 branch, so I'll leave the issue open for now.
> 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
> Fix For: 10.6.0.0
>
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Updated: (DERBY-4376) Simple select runs forever
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-4376:
-----------------------------------
Fix Version/s: 10.4.2.1
> 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
> Fix For: 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Assigned: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reassigned DERBY-4376:
-----------------------------------------
Assignee: Knut Anders Hatlen
> 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756087#action_12756087 ]
Knut Anders Hatlen commented on DERBY-4376:
-------------------------------------------
Created DERBY-4378 for the missing duplicate tests.
> 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
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761800#action_12761800 ]
Mamta A. Satoor commented on DERBY-4376:
----------------------------------------
Merged changes into 10.4 codeline with revision 821226. The only error I got was for BlobClob4BlobTest.testLockingWithLongRowBlob and it looks like DERBY-3740 although my testing was on windows xp machine using IBM16 jdk
1) testLockingBlob(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)junit.framework.AssertionFailedError: FAIL - should have gotten lock timeout
at org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest.testLockingBlob(BlobClob4BlobTest.java:2413)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:102)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 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
> Fix For: 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-4376) Simple select runs forever
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-4376:
-----------------------------------
Fix Version/s: 10.3.3.1
Merged into 10.3 codeline with 821557.
> 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
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Updated: (DERBY-4376) Simple select runs forever
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4376:
--------------------------------------
Issue & fix info: [Patch Available, Repro attached] (was: [Repro attached])
Yes, that's what I meant to say. Writing clearly would make it too easy for the readers... ;)
All the regression tests ran cleanly, so I'm checking Patch Available.
> 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
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.
[jira] Commented: (DERBY-4376) Simple select runs forever
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756089#action_12756089 ]
Bryan Pendleton commented on DERBY-4376:
----------------------------------------
Ha! I misread your comment at first and it made me do a double-take.
Then I re-read it, and realized that you meant "missing tests of duplicate values" :)
To keep this comment from being entirely light-hearted, I think your overall approach
(refactoring the logic so that MPTSRS can override it more cleanly) sounds excellent.
> 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
> Attachments: derby-4376-1a.diff, derby-4376-1a.stat
>
>
> 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.