Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <20234974.93921291385711409.JavaMail.jira@thor>
Date: Fri, 3 Dec 2010 09:15:11 -0500 (EST)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2949) AssertionFailedError in
 testStalePlansOnLargeTable
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-2949?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1296=
6542#action_12966542 ]=20

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 be=
have 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 t=
o 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, evi=
cting all pages currently in the cache, so that the row count changes are w=
ritten 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 checkpoin=
t. And it sounds like it was added in order to avoid exactly this kind of i=
ntermittent 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 b=
e at least as big as the page cache in order to achieve that, so the test n=
eeds 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 ta=
ble with explicit checkpoints. I'm leaning towards the latter option (using=
 checkpoints to flush the estimates), since that sounds like the simpler on=
e (no need to know exact size of the page cache or the exact number of page=
s 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=C2=A9 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=C3=BF967 Total Memory.
> JVM: Sun Microsystems Inc. 1.5.0_07-b03=20
>            Reporter: Henri van de Scheur
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: expected-plan.txt, plan.txt
>
>
> testStalePlansOnLargeTable(org.apache.derbyTesting.functionTests.tests.la=
ng.StalePlansTest)junit.framework.AssertionFailedError
> =09at org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest.tes=
tStalePlansOnLargeTable(StalePlansTest.java:264)
> =09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> =09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp=
l.java:39)
> =09at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc=
essorImpl.java:25)
> =09at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.jav=
a:88)
> =09at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> =09at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> =09at junit.extensions.TestSetup.run(TestSetup.java:25)
> =09at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:=
57)
> =09at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> =09at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> =09at junit.extensions.TestSetup.run(TestSetup.java:25)
> =09at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:=
57)

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.