Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 36365 invoked from network); 14 Mar 2006 01:05:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Mar 2006 01:05:17 -0000 Received: (qmail 36285 invoked by uid 500); 14 Mar 2006 01:05:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 36254 invoked by uid 500); 14 Mar 2006 01:05:16 -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 36245 invoked by uid 99); 14 Mar 2006 01:05:16 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar 2006 17:05:16 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar 2006 17:05:16 -0800 Received: from ajax (localhost.localdomain [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id EA0DFD49FE for ; Tue, 14 Mar 2006 01:04:54 +0000 (GMT) Message-ID: <2098589374.1142298294956.JavaMail.jira@ajax> Date: Tue, 14 Mar 2006 01:04:54 +0000 (GMT) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-1109) lang/predicatePushdown.sql fails with wsdd5.6 In-Reply-To: <135237185.1142296622548.JavaMail.jira@ajax> 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-1109?page=comments#action_12370278 ] A B commented on DERBY-1109: ---------------------------- This issue is the same as DERBY-1110--they both have the same query in them, and that query is failing with the same row-ordering diff. This diff is an interesting one: I've verified that for IBM wsdd the optimizer chooses the same join order that it chooses for all other JVMs--which is expected since the derby.optimizer.noTimeout flag is set to "true" for both lang/subquery.sql and lang/predicatePushdown.sql, and thus the optimizer should always choose the same plan, regardless of machine/platform. That said, I'm not sure what could be causing this specific difference in row ordering for IBM wsdd. I am able to reproduce the diff on my machine, but don't understand where it comes from. Since the optimizer is choosing the same join order for all platforms, I was assuming the row order should be the same, as well--but that's apparently not a safe assumption. I did notice that the queries that are failing have "DISTINCT" in them, so it's possible that the ordering of rows based on a DISTINCT is JVM-dependent somehow, which would explain this diff. Can anyone confirm that one way or the other? If this is just an _acceptable_ difference in JVM behavior, then there are two possible solutions here: either 1) create a wsdd-specific master, or 2) (and probably more preferably) add an "order by" clause to the queries in question to ensure that we get the same row order across JVMs. If, however, this difference in row order seems like incorrect behavior, then this would of course merit further investigation. Anyone have any input one way or the other? > lang/predicatePushdown.sql fails with wsdd5.6 > --------------------------------------------- > > Key: DERBY-1109 > URL: http://issues.apache.org/jira/browse/DERBY-1109 > Project: Derby > Type: Test > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: IBM wsdd5.6 j9_13 > Reporter: Deepa Remesh > > This test fails with the following diff: > 7507a7508,7509 > > 2 |1 > > 4 |2 > 7509,7510d7510 > < 4 |2 > < 2 |1 > 7632a7633,7636 > > 2 |1 > > 2 |1 > > 4 |2 > > 4 |2 > 7635,7638d7638 > < 4 |2 > < 4 |2 > < 2 |1 > < 2 |1 -- 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