Skip to content

Inspect segments under the per-segment lock in needReloadSegments()#18901

Open
gortiz wants to merge 1 commit into
apache:masterfrom
gortiz:need-reload-segments-under-segment-lock
Open

Inspect segments under the per-segment lock in needReloadSegments()#18901
gortiz wants to merge 1 commit into
apache:masterfrom
gortiz:need-reload-segments-under-segment-lock

Conversation

@gortiz

@gortiz gortiz commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Description

BaseTableDataManager.needReloadSegments() inspects each segment via
ImmutableSegment.isReloadNeeded()SegmentPreProcessor.needProcess(), which reads the
segment directory. It did so while holding only a reference count (from acquireAllSegments()),
not the per-segment lock (getSegmentLock) that reloadSegment / replaceSegment /
offloadSegment acquire. As a result, the reload-need check can run concurrently with a reload
of the same segment that is mutating or releasing that segment's backing resources.

This change inspects each segment under getSegmentLock(segmentName), and re-acquires the
segment fresh under the lock so a segment that a reload has already replaced is not inspected.
Segment names are snapshotted first, so the lock is never taken while holding segment references
(avoiding lock/refcount ordering surprises).

Notes

  • Behavior is unchanged in the common case (no concurrent reload); the check simply no longer
    races with a reload / replace / offload of the same segment.
  • The per-segment lock is the same striped lock already used by the reload path, so the check now
    serializes with an in-progress reload of that segment.

Testing

  • Existing table-data-manager tests pass.

needReloadSegments() inspected each segment via ImmutableSegment.isReloadNeeded()
-> SegmentPreProcessor.needProcess(), which reads the segment directory, while
holding only a reference count and not the per-segment lock that reload / replace /
offload acquire. That let the reload-need check race with a concurrent reload of the
same segment mutating or releasing its backing resources.

Inspect each segment under getSegmentLock(segmentName), re-acquiring it fresh under
the lock so a segment already replaced by a reload is not inspected. Segment names
are snapshotted first so the lock is not taken while holding segment references.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@codecov-commenter

codecov-commenter commented Jul 1, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.00%. Comparing base (f0329f3) to head (55bcd7a).
⚠️ Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
.../pinot/core/data/manager/BaseTableDataManager.java 0.00% 17 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (f0329f3) and HEAD (55bcd7a). Click for more details.

HEAD has 4 uploads less than BASE
Flag BASE (f0329f3) HEAD (55bcd7a)
java-21 5 4
unittests 2 1
temurin 5 4
unittests2 1 0
Additional details and impacted files
@@             Coverage Diff              @@
##             master   #18901      +/-   ##
============================================
- Coverage     64.80%   57.00%   -7.80%     
+ Complexity     1347        7    -1340     
============================================
  Files          3393     2607     -786     
  Lines        211664   152959   -58705     
  Branches      33305    24879    -8426     
============================================
- Hits         137160    87193   -49967     
+ Misses        63431    58346    -5085     
+ Partials      11073     7420    -3653     
Flag Coverage Δ
custom-integration1 100.00% <ø> (ø)
integration 100.00% <ø> (ø)
integration1 100.00% <ø> (ø)
integration2 0.00% <ø> (ø)
java-21 57.00% <0.00%> (-7.80%) ⬇️
temurin 57.00% <0.00%> (-7.80%) ⬇️
unittests 57.00% <0.00%> (-7.80%) ⬇️
unittests1 57.00% <0.00%> (+0.02%) ⬆️
unittests2 ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@Jackie-Jiang Jackie-Jiang left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary? I'd expect needReloadSegments() to be fast. Even if we switch to the per-segment lock, there is still no guarantee segment won't be deleted/replaced just after the check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants