You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2018/04/20 05:07:00 UTC
[jira] [Resolved] (CALCITE-2267) AbstractRelNode.getId() may
produce duplicate IDs in multi-threaded environment
[ 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)