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