neoremind created CALCITE-3924:
----------------------------------
Summary: 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
Attachments: common_first_error.log
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)
