-
Notifications
You must be signed in to change notification settings - Fork 848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not decompress batches for COPY with potentially invalid slot #6931
Conversation
We don't have to decompress anything more when we re-lookup the chunk insert state on COPY buffer flush, and the slots[0] is potentially invalid because the flush code processes empty buffers as well. Move decompression to a separate function for clarity.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6931 +/- ##
==========================================
+ Coverage 80.06% 80.88% +0.81%
==========================================
Files 190 199 +9
Lines 37181 37194 +13
Branches 9450 9700 +250
==========================================
+ Hits 29770 30084 +314
- Misses 2997 3234 +237
+ Partials 4414 3876 -538 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice improvement!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We don't have to decompress anything more when we re-lookup the chunk insert state on COPY buffer flush. Moreover, `ChunkInsertState.slots[0]` is incorrect slot type for `decompress_batches_for_insert()`, because it is a chunk slot, not a hypertable slot. This can lead to rare errors when the chunk insert states go out of cache. Just don't do this unnecessary lookup, and move decompression to a separate function for clarity. Add an assertion and test that detect the slot type mismatch on main. (cherry picked from commit 044322b)
We don't have to decompress anything more when we re-lookup the chunk insert state on COPY buffer flush. Moreover, `ChunkInsertState.slots[0]` is incorrect slot type for `decompress_batches_for_insert()`, because it is a chunk slot, not a hypertable slot. This can lead to rare errors when the chunk insert states go out of cache. Just don't do this unnecessary lookup, and move decompression to a separate function for clarity. Add an assertion and test that detect the slot type mismatch on main. (cherry picked from commit 044322b)
We don't have to decompress anything more when we re-lookup the chunk insert state on COPY buffer flush. Moreover, `ChunkInsertState.slots[0]` is incorrect slot type for `decompress_batches_for_insert()`, because it is a chunk slot, not a hypertable slot. This can lead to rare errors when the chunk insert states go out of cache. Just don't do this unnecessary lookup, and move decompression to a separate function for clarity. Add an assertion and test that detect the slot type mismatch on main. (cherry picked from commit 044322b)
We don't have to decompress anything more when we re-lookup the chunk insert state on COPY buffer flush. Moreover,
ChunkInsertState.slots[0]
is incorrect slot type fordecompress_batches_for_insert()
, because it is a chunk slot, not a hypertable slot. This can lead to rare errors when the chunk insert states go out of cache.Just don't do this unnecessary lookup, and move decompression to a separate function for clarity. Add an assertion and test that detect the slot type mismatch on main.
There was a related fix that improved the situation for empty copy buffers, but not for wrong slot type #6117
Fixes #6540