Re: Failure in lang/compressTable.sql with current 10.3 branch
Bryan Pendleton wrote: Ole Solberg wrote: I guess r566353 needs to be backported to 10.3 as well: Thanks Ole and Henri! I agree, that change looks like a perfect match for the diff I was seeing in compressTable. http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out?r1=566353r2=566352pathrev=566353 I'm not totally sure how this change ties in to any specific JIRA issues, though. The revision log for r566353 doesn't indicate which JIRA issue it belongs with. However, since it fixes the problem that I saw in the trunk, I went ahead and merged it back to the 10.3 branch. The merge was clean, and the test now passes in my environment, so I committed this change to subversion as revision 597922. Dan, it appears that this might have been related to the DERBY-1734 change that you merged from the trunk to the 10.3 branch. If merging r566353 from the trunk to 10.3 was *not* the right thing to do, please let us know. Ole, Henri: can you confirm that this test now passes with the latest copy of the 10.3 branch? 10.3 tests with r597922 show that this now passes: http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/FailReports/598016_bySig.html http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/598016_bySig.html http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/598016_bySig.html (5 out of 12 platforms done when writing this...) thanks, bryan -- Ole Solberg, Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: Failure in lang/compressTable.sql with current 10.3 branch
Ole Solberg wrote: I guess r566353 needs to be backported to 10.3 as well: Thanks Ole and Henri! I agree, that change looks like a perfect match for the diff I was seeing in compressTable. http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out?r1=566353r2=566352pathrev=566353 I'm not totally sure how this change ties in to any specific JIRA issues, though. The revision log for r566353 doesn't indicate which JIRA issue it belongs with. However, since it fixes the problem that I saw in the trunk, I went ahead and merged it back to the 10.3 branch. The merge was clean, and the test now passes in my environment, so I committed this change to subversion as revision 597922. Dan, it appears that this might have been related to the DERBY-1734 change that you merged from the trunk to the 10.3 branch. If merging r566353 from the trunk to 10.3 was *not* the right thing to do, please let us know. Ole, Henri: can you confirm that this test now passes with the latest copy of the 10.3 branch? thanks, bryan
Re: Failure in lang/compressTable.sql with current 10.3 branch
Hi Bryan! I also see it in my daily tests on 10.3. Look for instance at http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/596747_bySig.html It started to appear the 20th of November, so that might help? It appears on all platforms and under all jvm-versions. (see http://dbtg.thresher.com/derby/test/ - 10.3 Branch - daily) Henri Bryan Pendleton wrote: Hi all, I'm seeing a failure in lang/compressTable.sql with the current 10.3 branch. Is anyone else seeing this? The diff appears to involve a slight difference in the value of the last column in the SYS.SYSSTATISTICS catalog. Here's a snip from compressTable.tmpmstr: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP ||VALID|COLCOUNT |STATISTICS -- FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= And here's the equivalent section of my compressTable.out: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP ||VALID|COLCOUNT |STATISTICS - FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= 2 n This diff appears to occur in all the SYS.SYSSTATISTICS references in the DERBY-737 section of compressTable.sql. Does anyone have a suggestion as to what might be causing this? thanks, bryan
Re: Failure in lang/compressTable.sql with current 10.3 branch
Henri van de Scheur wrote:
Hi Bryan!
I also see it in my daily tests on 10.3. Look for instance at
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/596747_bySig.html
It started to appear the 20th of November, so that might help?
It appears on all platforms and under all jvm-versions.
(see http://dbtg.thresher.com/derby/test/ - 10.3 Branch - daily)
Henri
Bryan Pendleton wrote:
Hi all,
I'm seeing a failure in lang/compressTable.sql with the current 10.3
branch.
Is anyone else seeing this?
The diff appears to involve a slight difference in the value of the last
column in the SYS.SYSSTATISTICS catalog.
Here's a snip from compressTable.tmpmstr:
create index t2i1 on derby737table2(c1);
0 rows inserted/updated/deleted
ij select * from sys.sysstatistics;
STATID
|REFERENCEID |TABLEID
|CREATIONTIMESTAMP ||VALID|COLCOUNT |STATISTICS
--
FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true
|1 |numunique=
And here's the equivalent section of my compressTable.out:
create index t2i1 on derby737table2(c1);
0 rows inserted/updated/deleted
ij select * from sys.sysstatistics;
STATID
|REFERENCEID |TABLEID
|CREATIONTIMESTAMP ||VALID|COLCOUNT |STATISTICS
-
FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true
|1 |numunique= 2 n
This diff appears to occur in all the SYS.SYSSTATISTICS references in
the DERBY-737 section of compressTable.sql.
Does anyone have a suggestion as to what might be causing this?
thanks,
bryan
I guess r566353 needs to be backported to 10.3 as well:
11/21/2007 09:11 AM Ole Solberg (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544189
]
Ole Solberg commented on DERBY-1734:
2007-11-20 nightlies: 10.3 regression tests fails in
lang/CompressTable.sql.
Probably caused by r596490 which includes r564792:
We saw the same with r564792 on trunk. This was fixed by
r566353 | djd | 2007-08-15 23:45:33 +0200 (Wed, 15 Aug 2007) | 1 line
- Fix compressTable master file.
See e.g.
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/testSummary-596747.html
or http://dbtg.thresher.com/derby/test/stats_today.html as of
2007-11-21 (the -5001 entry).
Simplify building of SystemColumn array in CatalogRowFactory
implementations.
--
Key: DERBY-1734
URL: https://issues.apache.org/jira/browse/DERBY-1734
Project: Derby
Issue Type: Sub-task
Components: SQL
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
Fix For: 10.4.0.0
The implementations of CatalogRowFactory.buildColumnList() can be
simplified in a number of ways:
1) precision scale are always passed in as zero and can be removed
2) adding static factory methods to SystemColumnImpl would ease
the building of the arrays by not requiring the additional redundant
arguments the constructor call forces today, e.g. max length i snot
required to create an INTEGER column.
3) The column's position is not required to be stored in the
SytstemColumn class, it's defined by the position in the array
4) arrays can be built using
new SystemColumn[] { ... }
syntax instead of the existing
columnList[0] = ...
columnList[1] = ...
or
columnList[index++] = ...
columnList[index++] = ...
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
