Skip to content
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

Merged
merged 5 commits into from
May 23, 2024

Conversation

akuzm
Copy link
Member

@akuzm akuzm commented May 17, 2024

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.

There was a related fix that improved the situation for empty copy buffers, but not for wrong slot type #6117

Fixes #6540

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.
Copy link

codecov bot commented May 17, 2024

Codecov Report

Attention: Patch coverage is 66.66667% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 80.88%. Comparing base (59f50f2) to head (3d46450).
Report is 162 commits behind head on main.

Files Patch % Lines
src/nodes/chunk_dispatch/chunk_dispatch.c 75.00% 1 Missing and 2 partials ⚠️
tsl/src/compression/compression.c 40.00% 0 Missing and 3 partials ⚠️
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.
📢 Have feedback on the report? Share it here.

@akuzm akuzm marked this pull request as ready for review May 17, 2024 13:23
@akuzm akuzm added this to the TimescaleDB 2.15.1 milestone May 21, 2024
Copy link
Contributor

@antekresic antekresic left a comment

Choose a reason for hiding this comment

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

Very nice improvement!

Copy link
Member

@svenklemm svenklemm left a comment

Choose a reason for hiding this comment

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

LGTM

@akuzm akuzm enabled auto-merge (squash) May 23, 2024 09:03
@akuzm akuzm merged commit 044322b into timescale:main May 23, 2024
37 of 43 checks passed
@akuzm akuzm deleted the copy-decompress branch May 23, 2024 09:03
github-actions bot pushed a commit that referenced this pull request May 23, 2024
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)
fabriziomello pushed a commit that referenced this pull request May 25, 2024
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)
timescale-automation pushed a commit that referenced this pull request May 25, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Timescale segfaults when backfilling data
4 participants