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] Updated: (DERBY-4376) Simple select runs forever
Date Wed, 16 Sep 2009 15:27:57 GMT

     [ 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

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

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:,,
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: derby-4376-1a.diff, derby-4376-1a.stat
> On Derby 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 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.

View raw message