[
https://issues.apache.org/jira/browse/CALCITE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2267.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in
[f5b041ff|http://git-wip-us.apache.org/repos/asf/calcite/commit/f5b041ff];
thanks for the PR, [~zhong.j.yu]!
> AbstractRelNode.getId() may produce duplicate IDs in multi-threaded
> environment
> -------------------------------------------------------------------------------
>
> Key: CALCITE-2267
> URL: https://issues.apache.org/jira/browse/CALCITE-2267
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Zhong Yu
> Assignee: Julian Hyde
> Priority: Major
> Fix For: 1.17.0
>
>
> RelOptNode.getId() is supposed to be unique per instance; however, the
> generation of AbstractRelNode.id is not thread safe; in a multithreaded
> environment, the behavior is undeterministic, and there is a non-trivial
> possibility that duplicate IDs are generated for different nodes.
> This ID is used for comparing nodes in several places, therefore it may
> affect program stability and correctness. For example, if we set id=0 for all
> nodes, Calcite's own test suite will have multiple failures.
> In our own test environment, the optimizers are expected to be deterministic,
> yet occasionally they mysteriously produce different plans. While we cannot
> be 100% sure that it is caused by AbstractRelNode.id, we can verify that
> fudging with the ID will reliably change the output of our optimizers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
