[
https://issues.apache.org/jira/browse/CALCITE-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-3924.
---------------------------------
Fix Version/s: 1.23.0
Assignee: Danny Chen
Resolution: Fixed
Fixed in
[dfb842e|https://github.com/apache/calcite/commit/dfb842e55e1fa7037c8a731341010ed1c0cfb6f7],
thanks for your PR, [~neoremind] !
> Fix flakey test to handle TIMESTAMP and TIMESTAMP(0) correctly
> --------------------------------------------------------------
>
> Key: CALCITE-3924
> URL: https://issues.apache.org/jira/browse/CALCITE-3924
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.22.0
> Reporter: neoremind
> Assignee: Danny Chen
> Priority: Critical
> Labels: pull-request-available
> Fix For: 1.23.0
>
> Attachments: common_first_error.log
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently, building is not stable, there are frequently flakey tests on
> Linux(JDK 11) related with TIMESTAMP(0) vs TIMESTAMP.
> For example,
> [https://github.com/apache/calcite/runs/584340845]
> [https://github.com/apache/calcite/runs/576436249]
> [https://github.com/apache/calcite/runs/585695121]
> Below is first failure test of a consecutive failure tests from the three
> builds:
> _org.apache.calcite.test.SqlLimitsTest > testPrintLimits() (see attachment
> log for detail)_
> _The only diff is TIMESTAMP(0) vs TIMESTAMP_
>
> The root cause is:
> In BasicSqlType, the value of `toString` result and instance member `digest`
> might be different. For TIMESTAMP without precision (precision = -1),
> toString returns TIMESTAMP and digest is TIMESTAMP(0), which conflicts with
> real TIMESTAMP(0) with 0 as precision.
> `Interner<RelDataType> DATATYPE_CACHE = Interners.newWeakInterner()` makes
> sure SqlType is singleton between invocations, TIMESTAMP(0) might return
> SqlType - TIMESTAMP without precision literally which is wrong. Because the
> global cache uses weak reference, so the cache would usually invalidate after
> Java GC, which mitigates the impact of the hidden bug. As for the specific
> environment Linux JDK 11 situation, I could not give a reasonable explanation
> yet, but I suppose the cause is clear.
> The fix is simple, making the digest of TIMESTAMP without precision
> (precision = -1) as _TIMESTAMP_ instead of _TIMESTAMP(0)_ would solve the
> problem. This could expand to all TIME and TIMESTAMP related sql types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
