Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 40756 invoked from network); 26 Jun 2006 14:09:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Jun 2006 14:09:06 -0000 Received: (qmail 58436 invoked by uid 500); 26 Jun 2006 14:09:05 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 58397 invoked by uid 500); 26 Jun 2006 14:09:04 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 58305 invoked by uid 99); 26 Jun 2006 14:09:04 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 07:09:04 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 07:09:03 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 24035410009 for ; Mon, 26 Jun 2006 14:07:31 +0000 (GMT) Message-ID: <21728622.1151330851144.JavaMail.jira@brutus> Date: Mon, 26 Jun 2006 14:07:31 +0000 (GMT+00:00) From: "Andreas Korneliussen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-937) Instability in wisconsin test In-Reply-To: <1690588452.1139412931072.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12417814 ] Andreas Korneliussen commented on DERBY-937: -------------------------------------------- This test is failing pretty consistently on Windows. I looked at the properties for the test, and found this: #checkpoint influences the plans in some cases becuase rows count #getupdated on checkpoint, following is necessart to check some plans derby.storage.checkpointInterval=100000 Based on this, I have the following question: Does really the checkpointinterval influence this test ? The indexes are created after the tables are populated, so the statistics should be updated or ..? Would it make any difference to the test if we add a sleeping period after the population of the tables ? I think this could make a difference, if the failures are caused by the optimizer choosing plans based on outdated statistics. > Instability in wisconsin test > ----------------------------- > > Key: DERBY-937 > URL: http://issues.apache.org/jira/browse/DERBY-937 > Project: Derby > Type: Test > Components: Test, Regression Test Failure > Versions: 10.1.2.4 > Reporter: Rick Hillegas > Attachments: 10.1_05_05_06_failure.zip > > The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira