Failure in lang/compressTable.sql with current 10.3 branch
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
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
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=566353&r2=566352&pathrev=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
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=566353&r2=566352&pathrev=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