[
https://issues.apache.org/jira/browse/CALCITE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445113#comment-16445113
]
Zhong Yu commented on CALCITE-2267:
-----------------------------------
When there are multiple threads writing to `nextId`, Java memory model is
pretty loose and allows any value to be read -- in theory. Practically there is
a non-trivial chance that another thread overwrites `nextId` with a value
smaller than a thread last observed.
> 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)
