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-2949) AssertionFailedError in testStalePlansOnLargeTable
Date Fri, 03 Dec 2010 14:15:11 GMT

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

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

It may be possible to improve the accuracy/predictability of the row count estimate, but for
this issue I think we should just try to make the test behave predictably.

The test frequently executes the query "select count(c1) from flusher". The comments say this
about its purpose:

                // Create and populate a table to be used for flushing the
                // cache. Flushing the cache causes all row count changes to be
                // written, which is necessary for the results of this test to
                // be stable (because otherwise the row count changes would be
                // written asynchronously)

It sounds like the query is meant to fill the page cache with new data, evicting all pages
currently in the cache, so that the row count changes are written at a know point in time.
So the net effect, at least with respect to the row count estimate, should be the same as
what we get from a checkpoint. And it sounds like it was added in order to avoid exactly this
kind of intermittent failures.

However, I don't think the code works as intended because the FLUSHER table is not big enough
to flush all pages from the page cache. The table must be at least as big as the page cache
in order to achieve that, so the test needs to increase the size of the table or reduce the
size of the page cache (or both). Alternatively, we could replace the selects from the FLUSHER
table with explicit checkpoints. I'm leaning towards the latter option (using checkpoints
to flush the estimates), since that sounds like the simpler one (no need to know exact size
of the page cache or the exact number of pages in the FLUSHER table).

> AssertionFailedError in testStalePlansOnLargeTable
> --------------------------------------------------
>
>                 Key: DERBY-2949
>                 URL: https://issues.apache.org/jira/browse/DERBY-2949
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.3.1.4
>         Environment: Microsoft© Windows VistaT Ultimate - 6.0.6000 N/A Build 6000
> WindowsNT 0 6
> 2 X [Sun Fire X4100 Server x64 Family 15 Model 37 Stepping 1 AuthenticAMD]: ~2592 MHz,
 cache. 3ÿ967 Total Memory.
> JVM: Sun Microsystems Inc. 1.5.0_07-b03 
>            Reporter: Henri van de Scheur
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: expected-plan.txt, plan.txt
>
>
> testStalePlansOnLargeTable(org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest)junit.framework.AssertionFailedError
> 	at org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest.testStalePlansOnLargeTable(StalePlansTest.java:264)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

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