[ 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
