HIVE-28667: Error initializing field trimmer instance when starting HS2 #5879
+39
−13
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RelFieldTrimmer class is a reflection based visitor that tries to find the appropriate method based on the type (Class) of the argument. The errors occurs while trying to register a method dispatcher for `JdbcSort.class` since there are multiple candidate methods that qualify: * trimFields(JdbcRel rel, ImmutableBitSet fieldsUsed, Set<RelDataTypeField> extraFields) * trimFields(Sort sort, ImmutableBitSet fieldsUsed, Set<RelDataTypeField> extraFields) Given that there is no inheritance relationship between `Sort` and `JdbcRel` it is unclear which method should be used to handle JdbcSort leading to an exception that informs the user/dev about the ambiguous semantics. It seems that the intention of adding trimFields(JdbcRel...) method was to have a fallback for Jdbc operators that are not handled explicitly by the trimmer but this can never work and creates ambiguity as explained above. The reason that we get this error only during startup of HS2 and not during compilation is because in the current code it is impossible to call the RelFieldTrimmer code with Jdbc operators other than HiveJdbcConverter and JdbcHiveTableScan. 1. Change trimFields(JdbcRel) to trimFields(JdbcSort) to break the ambiguity and avoid the error. There is no change in behavior since anyways the trimmer cannot be called with a JdbcSort operator. 2. Make CalcitePlanner#HIVE_REL_NODE_CLASSES public mainly to facilitate testing. In fact, it makes sense to expose this information somewhere so why not in CalcitePlanner.
asf-ci-hive
added
tests pending
tests unstable
and removed
tests pending
tests unstable
labels
|
ngsg
reviewed
Jun 26, 2025
| @@ -587,6 +576,13 @@ public TrimResult trimFields( | |||
| return result(relBuilder.build(), inputMapping); | |||
| } | |||
|
|
|||
| public TrimResult trimFields( | |||
| JdbcSort rel, | |||
There was a problem hiding this comment.
If I understand correctly, trimFields for JdbcSort is now hiding trimFields for Sort. Then do we need trimFields for JdbcUnion to hide the one for SetOp as well?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
trimFields(JdbcRel)totrimFields(JdbcSort)to break the ambiguity and avoid the error.CalcitePlanner#HIVE_REL_NODE_CLASSESpublic mainly to facilitate testing. In fact, it makes sense to expose this information somewhere so why not in CalcitePlanner.Why are the changes needed?
Avoid the ambiguity exception during HS2 startup. For more details see commit message or HIVE-28667.
Does this PR introduce any user-facing change?
No. There is no change in behavior since anyways the trimmer cannot be called with a JdbcSort operator.
How was this patch tested?