[
https://issues.apache.org/jira/browse/CALCITE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444721#comment-16444721
]
Julian Hyde commented on CALCITE-2267:
--------------------------------------
I agree that generation is not thread-safe. But we require that each planner
(and the whole process to prepare a particular query, i.e. all RelNodes in the
same RelOptCluster) is used within a single thread. So IDs should be unique
within each planner.
It's still worth fixing. Maybe make change AbstractRelNode.nextId into an
AtomicInteger.
Also let's make AbstractRelNode.id final.
> AbstractRelNode.getId() may produce duplicate IDs
> -------------------------------------------------
>
> 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)
