Use local segment fieldInfos to lookup tsdb merge stats#132597
Merged
dnhatn merged 4 commits intoelastic:mainfrom Aug 9, 2025
Merged
Use local segment fieldInfos to lookup tsdb merge stats#132597dnhatn merged 4 commits intoelastic:mainfrom
dnhatn merged 4 commits intoelastic:mainfrom
Conversation
05076f2 to
2d5f28c
Compare
Collaborator
|
Hi @dnhatn, I've created a changelog YAML for you. |
Collaborator
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
martijnvg
approved these changes
Aug 9, 2025
Member
martijnvg
left a comment
There was a problem hiding this comment.
Thanks Nhat, very good find here. LGTM 👍
| for (int i = 0; i < mergeState.docValuesProducers.length; i++) { | ||
| final FieldInfo fieldInfo = mergeState.fieldInfos[i].fieldInfo(mergedFieldInfo.name); | ||
| if (fieldInfo == null) { | ||
| continue; |
Member
There was a problem hiding this comment.
This is similar to this if statement:
var wrapped = perFieldReader.getDocValuesProducer(fieldInfo);
if (wrapped == null) {
continue;
}
and so it is safe to continue here? (and we don't have to fallback to UNSUPPORTED)
Member
Author
There was a problem hiding this comment.
Yes, it should be safe to continue with the merge optimization. If the FieldInfo is null in some segments, it is safe to skip those and use the merge stats from segments that have values.
Member
Author
|
Thanks Martijn! |
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
dnhatn
added a commit
to dnhatn/elasticsearch
that referenced
this pull request
Aug 9, 2025
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates elastic#125403
elasticsearchmachine
pushed a commit
that referenced
this pull request
Aug 9, 2025
…32612) Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates #125403
Member
Author
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
dnhatn
added a commit
to dnhatn/elasticsearch
that referenced
this pull request
Aug 9, 2025
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates elastic#125403
elasticsearchmachine
pushed a commit
that referenced
this pull request
Aug 9, 2025
…32613) Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+. When shrinking an index to a single shard, we use addIndexes, which can add Lucene segments directly. In this case, FieldInfos can differ between shards and the new segment. We should use the FieldInfos from each segment to retrieve the merge stats, instead of the FieldInfos of the merged segment. Relates #125403
martijnvg
added a commit
that referenced
this pull request
Aug 11, 2025
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
Adding #132597 as known issue for 9.1.0-9.1.1
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
Adding #132597 as known issue for 8.19.0. Placing it at the very bottom just to be consistent with other release notes in the 8-series (though known issues are better positioned towards the top of the release notes -- after breaking changes).
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
Adding #132597 as known issue for 8.19.1. Placing it at the very bottom just to be consistent with other release notes in the 8-series (though known issues are better positioned towards the top of the release notes -- after breaking changes).
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
ppf2
added a commit
that referenced
this pull request
Aug 11, 2025
ppf2
added a commit
that referenced
this pull request
Aug 12, 2025
Reverting change based on the [comment](#132683 (comment)). Due to a PR CI issue, the [optimization](#125403) introduced in 8.19.0 that would have caused the [bug](#132597) didn't actually get enabled in 8.19.x versions. Therefore, 8.19.0 and 8.19.1 do not have either the optimization or the bug. The optimization will be enabled in 8.19.2 and the bug will be fixed by then.
ppf2
added a commit
that referenced
this pull request
Aug 12, 2025
Reverting change based on the [comment](#132683 (comment)). Due to a PR CI issue, the [optimization](#125403) introduced in 8.19.0 that would have caused the [bug](#132597) didn't actually get enabled in 8.19.x versions. Therefore, 8.19.0 and 8.19.1 do not have either the optimization or the bug. The optimization will be enabled in 8.19.2 and the bug will be fixed by then.
martijnvg
added a commit
to martijnvg/elasticsearch
that referenced
this pull request
Aug 14, 2025
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via elastic#132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
martijnvg
added a commit
to martijnvg/elasticsearch
that referenced
this pull request
Aug 14, 2025
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via elastic#132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Aug 14, 2025
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Aug 18, 2025
Be more strict about not finding a metadata entry based on field info number. If this were to happen, then this can cause issues in doc value consumer later. An example of such a failure is what is fixed via #132597, here with shrinking the local segment and merged field numbers were not aligned causing serious merge errors in the tsdb doc value consumer. Currently such an issue shouldn't occur anymore.
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
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.
Merging shrink TSDB or LogsDB indices can fail in versions 8.19 or 9.1+.
When shrinking an index to a single shard, we use addIndexes, which can
add Lucene segments directly. In this case, FieldInfos can differ
between shards and the new segment. We should use the FieldInfos from
each segment to retrieve the merge stats, instead of the FieldInfos of
the merged segment.
Relates #125403