You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <de...@db.apache.org> on 2006/02/08 16:35:31 UTC
[jira] Created: (DERBY-937) Instability in wisconsin test
Instability in wisconsin test
-----------------------------
Key: DERBY-937
URL: http://issues.apache.org/jira/browse/DERBY-937
Project: Derby
Type: Test
Reporter: Rick Hillegas
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
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Mike Matrigali updated DERBY-937:
---------------------------------
Fix Version: 10.2.0.0
committed
> 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
> Assignee: Andreas Korneliussen
> Fix For: 10.2.0.0
> Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat
>
> 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
[jira] Closed: (DERBY-937) Instability in wisconsin test
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Rick Hillegas closed DERBY-937:
-------------------------------
> 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
> Assignee: Andreas Korneliussen
> Fix For: 10.2.0.0
> Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat
>
> 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
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Mike Matrigali <mi...@sbcglobal.net>.
If you don't mind, I think this is worth reporting as a separate new
issue. The previous diffs were only different plans, it looks like
a new bug has crept in -- which is always likely if an intermittent
failure is unresolved such that everyone just starts ignoring the
failing test.
Sunitha Kambhampati (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
>
> Sunitha Kambhampati updated DERBY-937:
> --------------------------------------
>
> Attachment: 10.1_05_05_06_failure.zip
>
> Attaching test diff files for the failure on 10.1 on 05/05/2006.
>
>
>>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.
>
>
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Sunitha Kambhampati updated DERBY-937:
--------------------------------------
Attachment: 10.1_05_05_06_failure.zip
Attaching test diff files for the failure on 10.1 on 05/05/2006.
> 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
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Mike Matrigali updated DERBY-937:
---------------------------------
Component: Regression Test Failure
Test
I am now also seeing this test fail in my standard development enviornment: windows XP, single processor ~1.8 ghz laptop, sane classes, both sun jdk1.4 and sun jdk 1.5. I had not seen this failure in my test runs in the sun jdk1.4 environment before 3/3/06.
An example diff, from a clean build on trunk:
*** Start: wisconsin jdk1.5.0_02 2006-03-06 12:42:01 ***
0a1
> -- SecurityManager not installed --
594 del
< Nested Loop Exists Join ResultSet:
594a595
> Hash Exists Join ResultSet:
605 del
< Nested Loop Exists Join ResultSet:
605a606
> Hash Exists Join ResultSet:
645 del
< Columns accessed from heap = {0, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
645a646
> Columns accessed from heap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
650 del
< Index Scan ResultSet for TENKTUP1 using index TK1UNIQUE2 at serializable isolation level using share row locking chosen by the optimizer
650a651
> Hash Scan ResultSet for TENKTUP1 using index TK1UNIQUE2 at serializable isolation level using share row locking:
651a653,654
> Hash table size = 1000
> Hash key is column number 0
654d656
< Fetch Size = 1
664 del
< Number of pages visited=2
665 del
< Number of rows qualified=1
666 del
< Number of rows visited=1
666a666,668
> Number of pages visited=7
> Number of rows qualified=1000
> Number of rows visited=1001
669a672,673
> None
> stop position:
673 del
< stop position:
674 del
< > on first 1 column(s).
675 del
< Ordered null semantics on the following columns:
676 del
< 0
677 del
< qualifiers:
677a677,679
> scan qualifiers:
> None
> next qualifiers:
679 del
< Operator: <
679a681
> Operator: =
687 del
< Columns accessed from heap = {0, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
687a689
> Columns accessed from heap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
692 del
< Index Scan ResultSet for TENKTUP2 using index TK2UNIQUE2 at serializable isolation level using share row locking chosen by the optimizer
692a694
> Hash Scan ResultSet for TENKTUP2 using index TK2UNIQUE2 at serializable isolation level using share row locking:
693a696,697
> Hash table size = 1000
> Hash key is column number 0
696d699
< Fetch Size = 1
705 del
< Number of pages visited=0
706 del
< Number of rows qualified=0
707 del
< Number of rows visited=0
707a708,710
> Number of pages visited=7
> Number of rows qualified=1000
> Number of rows visited=1001
710a714,715
> None
> stop position:
714 del
< stop position:
715 del
< > on first 1 column(s).
716 del
< Ordered null semantics on the following columns:
717 del
< 0
718 del
< qualifiers:
718a719,721
> scan qualifiers:
> None
> next qualifiers:
724,728d726
< Column[0][1] Id: 0
< Operator: <
< Ordered nulls: false
< Unknown return value: false
< Negate comparison result: false
984 del
< Nested Loop Exists Join ResultSet:
984a982
> Hash Exists Join ResultSet:
995 del
< Nested Loop Exists Join ResultSet:
995a993
> Hash Exists Join ResultSet:
1035 del
< Columns accessed from heap = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
1035a1033
> Columns accessed from heap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
1040 del
< Index Scan ResultSet for TENKTUP1 using index TK1UNIQUE1 at serializable isolation level using share row locking chosen by the optimizer
1040a1038
> Hash Scan ResultSet for TENKTUP1 using index TK1UNIQUE1 at serializable isolation level using share row locking:
1041a1040,1041
> Hash table size = 1000
> Hash key is column number 0
1044d1043
< Fetch Size = 1
1054 del
< Number of pages visited=2
1055 del
< Number of rows qualified=1
1056 del
< Number of rows visited=1
1056a1053,1055
> Number of pages visited=7
> Number of rows qualified=1000
> Number of rows visited=1001
1059a1059,1060
> None
> stop position:
1063 del
< stop position:
1064 del
< > on first 1 column(s).
1065 del
< Ordered null semantics on the following columns:
1066 del
< 0
1067 del
< qualifiers:
1067a1064,1066
> scan qualifiers:
> None
> next qualifiers:
1069 del
< Operator: <
1069a1068
> Operator: =
1077 del
< Columns accessed from heap = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
1077a1076
> Columns accessed from heap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}
1082 del
< Index Scan ResultSet for TENKTUP2 using index TK2UNIQUE1 at serializable isolation level using share row locking chosen by the optimizer
1082a1081
> Hash Scan ResultSet for TENKTUP2 using index TK2UNIQUE1 at serializable isolation level using share row locking:
1083a1083,1084
> Hash table size = 1000
> Hash key is column number 0
1086d1086
< Fetch Size = 1
1095 del
< Number of pages visited=0
1096 del
< Number of rows qualified=0
1097 del
< Number of rows visited=0
1097a1095,1097
> Number of pages visited=7
> Number of rows qualified=1000
> Number of rows visited=1001
1100a1101,1102
> None
> stop position:
1104 del
< stop position:
1105 del
< > on first 1 column(s).
1106 del
< Ordered null semantics on the following columns:
1107 del
< 0
1108 del
< qualifiers:
1108a1106,1108
> scan qualifiers:
> None
> next qualifiers:
1114,1118d1113
< Column[0][1] Id: 0
< Operator: <
< Ordered nulls: false
< Unknown return value: false
< Negate comparison result: false
Test Failed.
*** End: wisconsin jdk1.5.0_02 2006-03-06 12:43:02 ***
> Instability in wisconsin test
> -----------------------------
>
> Key: DERBY-937
> URL: http://issues.apache.org/jira/browse/DERBY-937
> Project: Derby
> Type: Test
> Components: Regression Test Failure, Test
> Reporter: Rick Hillegas
>
> 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
[jira] Resolved: (DERBY-937) Instability in wisconsin test
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Mike Matrigali resolved DERBY-937:
----------------------------------
Resolution: Fixed
I am closing this "intermittent" bug with fix committed as: 418108. If it shows up again file a new issue with the new details.
> 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
> Assignee: Andreas Korneliussen
> Fix For: 10.2.0.0
> Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat
>
> 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12378735 ]
Deepa Remesh commented on DERBY-937:
------------------------------------
wisconsin test has been enabled to run with j2me/foundation only in the trunk. It was not enabled in 10.1 branch. The exclude lines got removed from wisconsin_app.properties as part of port for DERBY-616 and hence we are seeing the failure.
The issue "ERROR 40XT0: An internal error was identified by RawStore module" is actually caused by another exception which can be seen earlier in the diff file: "ERROR XJ001: Java exception: java.math.BigDecimal: java.lang.NoClassDefFoundError'." This exception is expected as BigDecimal class is not available in this environment.
> 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12369112 ]
A B commented on DERBY-937:
---------------------------
I noticed that the wisconsin test attempts to run with the "noTimeout" property set to true, but in the wisconsin_derby.properties file, there's actually a typo:
derby.optimize.noTimeout=true
There is an "r" missing after the word "optimize"; i.e. the property should be:
derby.optimizer.noTimeout=true
While I am still unable to reproduce the diff on my own machine, and while the Tinderbox tests on most platforms do _not_ show the diff you posted, it's nonetheless possible that for different machines the optimizer is timing out at different times, causing the diff.
With that in mind I corrected the typo locally and re-ran the test; when I did so, it still passed for me. So if possible could you (or anyone else seeing this diff) correct the typo in wisconsin_derby.properties file and then run again to see if the test still fails?
March 3rd was the day my optimizer changes for DERBY-805 went into the codeline, so if the test has been failing consistently for you since then, and if fixing the properties typo doesn't help, then I'll have to look more closely at this to see what role my DERBY-805 changes might have here...
Thanks.
> Instability in wisconsin test
> -----------------------------
>
> Key: DERBY-937
> URL: http://issues.apache.org/jira/browse/DERBY-937
> Project: Derby
> Type: Test
> Components: Regression Test Failure, Test
> Reporter: Rick Hillegas
>
> 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12378686 ]
Sunitha Kambhampati commented on DERBY-937:
-------------------------------------------
With derby jars at 10.1.2.4 - (400222) , 05/05 regression test run of derbyall on 10.1 codeline shows failure with wisconsin test with wctme5.7. In the diff, at the end -there is this line.
> ERROR 40XT0: An internal error was identified by RawStore module.
I'll attach the report and other files to this issue.
> 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
>
> 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12378727 ]
Kathey Marsden commented on DERBY-937:
--------------------------------------
The issue of > ERROR 40XT0: An internal error was identified by RawStore module. sounds like a different issue. The only instability I know of is a difference in plans.
> 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
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Andreas Korneliussen (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
>
> Andreas Korneliussen updated DERBY-937:
> ---------------------------------------
>
> Attachment: DERBY-937.diff
> DERBY-937.stat
>
> I was able to reproduce this problem on every run on a very fast laptop (it was not reproducible on any other Windows lab machine I have tried). This laptop happens to be the same kind as Ole uses for the nightly tests.
>
> Adding a 10 second sleeping period after the population of the tables, did not have any effect. I therefore tried to do run a compress on the tables (based on the assumption that statistics is updated on compress), and now the test does not fail for me anymore.
>
> Attached is the patch which makes this test stop failing. The patch does not seem to have any sideeffects on other platforms (Solaris) tested, however the test will use more time.
It is great that this fixes the problem on your reproducible case, I say
we should commit. But I don't know why it does. To me it looks like
the loader program always first inserts all the data into the base
tables and then creates the indexes. In this case Derby automatically
creates the "statistics" that you mention here, and they should be
no different than what is recreated when you do the compress. Also
derby will create "packed" indexes in this case which again should look
no different than what compress will do (since all that has happened
are inserts into the table - if deletes or updates were involved it
would be a different story).
What the change does do is alter the cache a lot, and alter the I/O
timing a lot.
Also I wanted to again make sure people understand what statistics
mean in derby.
What is usually called "statistics" in other db's comes in 3 forms
in derby:
1) key distribution information
o this is automatically maintained by derby by using existing
indexes, no user interaction is ever needed and it is always up
to date. Basically we use the index itself to estimate a given
number of rows for a range of keys. Most other db's I know require
some sort of "update statistics" to get this info.
2) base table row counts
o also automatically maintained by derby, but can be slightly out
of date as it is only an estimate for performance reasons. Row
counts are updated at insert/delete time on a per page basis
automatically, but we delay the rollup. The rollup is done
always when the page goes to disk. The rollup may also be done
earlier if the change is significant to the total - I think if
delta is 10% or more of the table. The row count estimate is also
updated if they system ever happens to do a full scan on the
table.
3) cardinality statistic
This is basically one number which is the average number of duplicate
keys for a given key, where key is a leading set of columns in an
index. So a one key index has one number and an index with 3
columns (a, b, c) has 3 numbers indicating the cardinality of (a), (a,
b) and
(a, b, c).
o This statistic is automatically created when an index is created,
and also when a number of "bait/switch" ddl operations are done like
compress table. There have been a number of discussions on the list
on how to automate the update of this. My opinion is that we should
attack it in the following 3 ways:
o provide a way for users to schedule it to be calculated, other than by
running compress. Not greate for a zero-admin - just a work around
until we can better automate it. The code exists, just not shown
through to users right now.
o Develop a back ground "zero-admin" component which would
programtically figure out how and when to schedule this kind of activity.
o see if there is any smart quick way to estimate the values
automatically by doing some statistical analysis of the the btree
leaf pages.
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Andreas Korneliussen updated DERBY-937:
---------------------------------------
Attachment: DERBY-937.diff
DERBY-937.stat
I was able to reproduce this problem on every run on a very fast laptop (it was not reproducible on any other Windows lab machine I have tried). This laptop happens to be the same kind as Ole uses for the nightly tests.
Adding a 10 second sleeping period after the population of the tables, did not have any effect. I therefore tried to do run a compress on the tables (based on the assumption that statistics is updated on compress), and now the test does not fail for me anymore.
Attached is the patch which makes this test stop failing. The patch does not seem to have any sideeffects on other platforms (Solaris) tested, however the test will use more time.
> 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, DERBY-937.diff, DERBY-937.stat
>
> 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
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Sunitha Kambhampati updated DERBY-937:
--------------------------------------
Version: 10.1.2.4
> 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
>
> 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
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Øystein Grøvlen <Oy...@Sun.COM>.
Mike Matrigali wrote:
> I was working under the assumption that the wisc diffs were the kinds of
> issues we had seen in the past. Where the optimizer had 2 different
> plans which were very close in costing, and due to slight differences in
> estimates one plan was chosen over another.
The exception in this case, if I have understood things correctly, is
that one is not able to explain why there is a slight difference in
estimates and why the fix solves the problem. That is why I feel a JIRA
should be filed to indicate that something else may be wrong here so
that one remember to investigate this further.
> If anyone has done the careful analysis of the different plans and found
> that there is a serious problem with the plans the optimizer was picking
> please go ahead and report a new bug with that info and how to reproduce.
I have not done any careful analysis of the query plans, but as far as I
have understood, before the fix, the test was as follows:
1. Create table
2. Insert data
3. Create indexes
4. Execute query
The problem was that not the same query plan was chosen every time.
However, if you insert a compress between 3. and 4., the same query plan
is chosen every time. In other words, a compress may affect which plan
is chosen. You are saying that since the indexes is just created, a
subsequent compress should not change estimates. So what makes the plan
change in that case? I think it would be good to investigate that.
> My main concern was that spurious "expected" diffs means that almost
> everyone is just going to ignore any real future bug the test might
> show up.
I totally agree that we needed to fix the test since it was failing so
often and doing it this way is better than suspending the entire test.
However, we should be aware that we are fixing the test without actually
knowing whether the problem is really in the test or in the product.
--
Øystein
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> Mike is right: If these tests reliably generate noise, they will be
> ignored. This is pretty much equivalent to option (3).
>
>
wisconsin like stress multi can be a trouble maker but it is one of my
favorite tests. In the past it has frequently exposed memory leaks and
other serious issues. I would really not like to see it go.
Kathey
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Rick Hillegas <Ri...@Sun.COM>.
Mike Matrigali wrote:
>
>
> Oystein Grovlen - Sun Norway wrote:
>
>>
>> While it is good that we get this noise out of derbyall, it seems
>> like this fix covers up a problem that we do not quite understand.
>> As far as I have understood, it seems like the optimizer due to some
>> timing issues does not use the indexes. I think we should file a
>> JIRA for this problem.
>>
>
> I was working under the assumption that the wisc diffs were the kinds of
> issues we had seen in the past. Where the optimizer had 2 different
> plans which were very close in costing, and due to slight differences in
> estimates one plan was chosen over another.
>
> If anyone has done the careful analysis of the different plans and
> found that there is a serious problem with the plans the optimizer was
> picking please go ahead and report a new bug with that info and how to
> reproduce.
>
> My main concern was that spurious "expected" diffs means that almost
> everyone is just going to ignore any real future bug the test might
> show up.
>
I agree with what Mike said. I have worked for several database
companies and at all of these companies, optimizer choices were
notoriously subject to machine characteristics and therefore optimizer
output was problematic for regression tests. I have seen this issue
handled three ways:
1) An optimizer expert volunteers to monitor the optimizer drift in the
nightly regression tests and judge whether the drift is signal or noise.
2) The tests are re-coded to check for something less noisy than
optimizer output.
3) The tests are removed from the standard regression suite and only run
at the discretion of the optimizer experts.
Mike is right: If these tests reliably generate noise, they will be
ignored. This is pretty much equivalent to option (3).
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Oystein Grovlen - Sun Norway wrote:
>
> While it is good that we get this noise out of derbyall, it seems like
> this fix covers up a problem that we do not quite understand. As far as
> I have understood, it seems like the optimizer due to some timing
> issues does not use the indexes. I think we should file a JIRA for this
> problem.
>
I was working under the assumption that the wisc diffs were the kinds of
issues we had seen in the past. Where the optimizer had 2 different
plans which were very close in costing, and due to slight differences in
estimates one plan was chosen over another.
If anyone has done the careful analysis of the different plans and found
that there is a serious problem with the plans the optimizer was picking
please go ahead and report a new bug with that info and how to reproduce.
My main concern was that spurious "expected" diffs means that almost
everyone is just going to ignore any real future bug the test might
show up.
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Mike Matrigali (JIRA) wrote:
> I ran this change 20 times and it worked on my laptop, it would always fail
> a few times out of 20 before the fix. I am not sure why this fix works as
> the test seems to already create indexes after tables so statistics should
> already be up to date.
While it is good that we get this noise out of derbyall, it seems like
this fix covers up a problem that we do not quite understand. As far as
I have understood, it seems like the optimizer due to some timing
issues does not use the indexes. I think we should file a JIRA for this
problem.
--
Øystein
[jira] Updated: (DERBY-937) Instability in wisconsin test
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Mike Matrigali updated DERBY-937:
---------------------------------
committed change to trunk:
r418108 | mikem | 2006-06-29 11:27:51 -0700 (Thu, 29 Jun 2006) | 16 lines
DERBY-937, committing change by Andreas Korneliussen.
notes by Andreas:
I was able to reproduce this problem on every run on a very fast laptop (it was
not reproducible on any other Windows lab machine I have tried). This laptop hap
pens to be the same kind as Ole uses for the nightly tests.
Adding a 10 second sleeping period after the population of the tables, did not h
ave any effect. I therefore tried to do run a compress on the tables (based on t
he assumption that statistics is updated on compress), and now the test does not
fail for me anymore.
Attached is the patch which makes this test stop failing. The patch does not see
m to have any sideeffects on other platforms (Solaris) tested, however the test
will use more time.
note by mike:
I ran this change 20 times and it worked on my laptop, it would always fail
a few times out of 20 before the fix. I am not sure why this fix works as
the test seems to already create indexes after tables so statistics should
already be up to date.
> 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
> Assignee: Andreas Korneliussen
> Fix For: 10.2.0.0
> Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat
>
> 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
[jira] Assigned: (DERBY-937) Instability in wisconsin test
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ]
Andreas Korneliussen reassigned DERBY-937:
------------------------------------------
Assign To: Andreas Korneliussen
> 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
> Assignee: Andreas Korneliussen
> Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat
>
> 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-937) Instability in wisconsin test
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-937?page=comments#action_12378786 ]
Sunitha Kambhampati commented on DERBY-937:
-------------------------------------------
I opened DERBY-1311 for the wisconsin failure on 05/05/2006 on 10.1/wctme5.7 foundation. ( previous 3 comments).
> 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