[
https://issues.apache.org/jira/browse/DERBY-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren closed DERBY-1221.
-------------------------------------
Resolution: Invalid
This was indeed a JVM issue and was fixed with the next version of the JVM.
> runtimestatistics time shows large number instead of 0 with ibm15 on zOS
> ------------------------------------------------------------------------
>
> Key: DERBY-1221
> URL: https://issues.apache.org/jira/browse/DERBY-1221
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.1
> Environment: zOS with ibm15
> Reporter: Myrna van Lunteren
>
> A number of tests that printout runtimestatistics fail on zOS with ibm15,
> because instead of a 'time' of 0, the time is some large number.
> Tests that fail like this:
> derbylang/derbylang.fail:lang/aggregateOptimization.sql
> derbylang/derbylang.fail:lang/distinctElimination.sql
> derbylang/derbylang.fail:lang/predicatePushdown.sql
> derbylang/derbylang.fail:lang/predicatesIntoViews.sql
> derbylang/derbylang.fail:lang/staleplans.sql
> derbylang/derbylang.fail:lang/wisconsin.java
> encryptionAll/encryption/storemats.fail:store/access.sql (in various
> encryption schemes)
> This is the kind of diff I see:
> ---------------------
> *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
> 2912 del
> < Execute Time = 0
> 2912a2912
> > Execute Time = -3638779204078642344
> 2921 del
> < next time (milliseconds) = 0
> 2921a2921
> > next time (milliseconds) = 3638779204078642344
> 2934 del
> < next time (milliseconds) = 0
> 2934a2934
> > next time (milliseconds) = 3668750241784351640
> 2991 del
> < Execute Time = 0
> 2991a2991
> > Execute Time = -4015137258338621104
> 3000 del
> < next time (milliseconds) = 0
> 3000a3000
> > next time (milliseconds) = 4015137258338621104
> ....
> ------------------------------
> As this problem occurs only with ibm15 and not with ibm14, I think somewhere
> in the runtime statistics printing code we may be using BigDecimal somehow,
> and it's not done in an encoding-safe way. But that is just a guess.
> I'm leaving this one as Major, because it's easy to miss things when looking
> through test failures this way, but I can also understand that this would be
> considered minor, as apparently the paths taken by the optimizer are actually
> correct and it's only the printing out that has the large numbers. Yet again
> on the other hand I imagine it makes runtimestatistics less useful, with
> these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
