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 03:33:00 UTC
[jira] [Updated] (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 updated CALCITE-2267:
---------------------------------
Summary: AbstractRelNode.getId() may produce duplicate IDs in multi-threaded environment (was: AbstractRelNode.getId() may produce duplicate IDs)
> 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
>
> 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)