[
https://issues.apache.org/jira/browse/DERBY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968733#action_12968733
]
Knut Anders Hatlen commented on DERBY-2949:
-------------------------------------------
It also looks like it will be more reliable to invoke a checkpoint explicitly.
Even if we make the flusher table bigger or the page cache smaller, filling up
the page cache with the flusher table does not mean every dirty page will be
written to disk immediately. The page cache will just schedule work with the
background worker thread, so we'd have to wait for some time in order to be
sure that the row counts have actually been updated. SYSCS_CHECKPOINT_DATABASE,
on the other hand, won't return until the dirty pages have been written to disk.
If I only change flushRowCount() to call SYSCS_CHECKPOINT_DATABASE(),
testStalePlansOnLargeTable() starts failing consistently. The problem appears
to be that the row count change is not significant enough to trigger a
recompile at a time where the test expects the plan to change. A significant
change is 10% when the table has more than 400 rows (see
BaseActivation.informOfRowCount()). The actual change in the row count at that
point was less than 1%, but it used to work before because the initial row
count estimate was inaccurate and the change therefore appeared to be larger. I
think the solution is to add more rows to the table to make sure the row count
changes sufficiently to always trigger a recompile.
> 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.
