Cap refresh start when hypertable has tiered data#9811
Open
kpan2034 wants to merge 4 commits into
Open
Conversation
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
0ef8281 to
3e5c07d
Compare
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
3e5c07d to
221041a
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
221041a to
fbd5fcd
Compare
|
@melihmutlu, @natalya-aksman: please review this pull request.
|
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
fbd5fcd to
1ed30b3
Compare
kpan2034
changed the title
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
1ed30b3 to
3ddfbf5
Compare
melihmutlu
reviewed
Jun 8, 2026
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
2 times, most recently
from
f4a57f4 to
e9c4ce4
Compare
Currently during a refresh, we process the ranges before the earliest chunk in the hypertable as well. This can lead to potential missing data when tiered data is present but tiered reads are disabled during the refresh. By capping the refresh range at the start of the earliest chunk, any invalidations before the earliest chunk are no longer processed and removed. Thus, in a subsequent refresh, if tiered data reads are enabled, that data would be materialized in the CAgg. We only need to do this when the hypertable has tiered data. Any new tiered data will either have been processed before tiering (since it exists in some chunk) or will be inserted after this refresh (which will generate invalidations).
Capping is done incorrectly when the OSM chunk is the earliest chunk.
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
e9c4ce4 to
ddca3ff
Compare
Incremental batch generation would generate batches considering tiered data ranges, even if tiered reads are disabled. This can lead to invalid batches since we cap the refresh start to the earliest chunk in the hypertable during the refresh.
kpan2034
force-pushed
the
cap-invals-at-chunk-min
branch
from
6d40793 to
ff7856d
Compare
melihmutlu
reviewed
Jun 15, 2026
Comment on lines
+228
to
+232
| ---------------------------------------------------------------------- | ||
| -- Test 5: When the OSM chunk's range is updated to precede the | ||
| -- earliest real chunk, the wrong dimension slice is picked up | ||
| -- and the refresh is not capped correctly. | ||
| ---------------------------------------------------------------------- |
Member
There was a problem hiding this comment.
the comment needs an update as it can cap correctly now.
Comment on lines
+1189
to
+1196
| *slice = dimension_slice_from_slot(ti->slot); | ||
| MemoryContextSwitchTo(old); | ||
| Chunk *chunk = ts_chunk_get_by_id((*slice)->fd.chunk_id, true); | ||
|
|
||
| if (IS_OSM_CHUNK(chunk)) | ||
| { | ||
| return SCAN_CONTINUE; | ||
| } |
Member
There was a problem hiding this comment.
*slice here assigned whether it's an osm chunk or not. Imagine a case where there is no non-osm chunk and all data is tiered, we would end up this *slice already assigned. The caller assumes that it's non-osm as long as it's not NULL which does not hold in this case.
We should either check again in the caller, or nullify *slice if it's osm in the later IS_OSM_CHUNK check here.
Comment on lines
+1337
to
+1346
| int64 earliest_start = invalidation_get_earliest_chunk_start(cagg->data.raw_hypertable_id); | ||
| if (earliest_start != INVAL_NEG_INFINITY) | ||
| { | ||
| Invalidation boundary = { .lowest_modified_value = earliest_start, | ||
| .greatest_modified_value = earliest_start }; | ||
| invalidation_expand_to_bucket_boundaries(&boundary, | ||
| cagg->partition_type, | ||
| cagg->bucket_function); | ||
| earliest_start = boundary.greatest_modified_value; | ||
| } |
Member
There was a problem hiding this comment.
I understand why we want to ignore anything before the value initially return by invalidation_get_earliest_chunk_start. But why do we move earliest_start to its bucket end which is a further value?
I feel like skipping the whole bucket as if it's not invalidated may trigger rewrite to use the cagg when the specific bucket is actually stale in the cagg.
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
6 participants
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.
Currently during a refresh, we process the ranges before the earliest chunk in the hypertable as well. This can lead to potential missing data when tiered data is present but tiered reads are disabled during the refresh.
By capping the refresh range at the start of the earliest chunk, any invalidations before the earliest chunk are no longer processed and removed. Thus, in a subsequent refresh, if tiered data reads are enabled, that data would be materialized in the CAgg.
We only need to do this when the hypertable has tiered data. Any new tiered data will either have been processed before tiering (since it exists in some chunk) or will be inserted after this refresh (which will generate invalidations).
We also cap the refresh start when generating batches for an incremental refresh.