Skip to content

Fix dump/restore when chunk skipping is enabled #8211

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

Merged
merged 2 commits into from
Jun 10, 2025

Conversation

erimatnor
Copy link
Member

@erimatnor erimatnor commented Jun 3, 2025

The chunk skipping feature uses a "special" entry in the catalog table chunk_column_stats to indicate that chunk skipping is enabled for that column. The special entry has the chunk_id column set to 0. However, at the same time the table schema defines a foreign key on the chunk_id column where the 0 entry violates that constraint. This prevents a dump/restore from working when such an entry is present.

To fix this issue, change the schema for chunk column stats to use NULL instead of 0 for "chunk_id" to indicate the special entry. Foreign keys work with such NULL entries so the foreign key can remain.

Add an update test to ensure that pg_dump/pg_restore works properly.

Fixes: #8130

Disable-check: commit-count

@erimatnor erimatnor force-pushed the remove-column-stats-fk branch 3 times, most recently from b91f94d to f5efdaa Compare June 3, 2025 10:25
Copy link

codecov bot commented Jun 3, 2025

Codecov Report

Attention: Patch coverage is 84.00000% with 8 lines in your changes missing coverage. Please review.

Project coverage is 81.98%. Comparing base (42a1c3a) to head (fd474b0).
Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
src/ts_catalog/chunk_column_stats.c 84.00% 1 Missing and 7 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #8211      +/-   ##
==========================================
- Coverage   82.37%   81.98%   -0.40%     
==========================================
  Files         256      256              
  Lines       48135    48129       -6     
  Branches    12141    12141              
==========================================
- Hits        39653    39457     -196     
- Misses       3615     3879     +264     
+ Partials     4867     4793      -74     

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@erimatnor erimatnor force-pushed the remove-column-stats-fk branch from f5efdaa to 2305074 Compare June 3, 2025 11:52
@erimatnor erimatnor marked this pull request as ready for review June 3, 2025 11:56
@github-actions github-actions bot requested review from gayyappan and svenklemm June 3, 2025 11:57
Copy link

github-actions bot commented Jun 3, 2025

@gayyappan, @svenklemm: please review this pull request.

Powered by pull-review

Copy link
Member

@mkindahl mkindahl left a comment

Choose a reason for hiding this comment

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

We should probably use NULL to represent this, since NULL means "no association with the referenced table", which is essentially what "invalid hypertable" means.

@erimatnor
Copy link
Member Author

We should probably use NULL to represent this, since NULL means "no association with the referenced table", which is essentially what "invalid hypertable" means.

@mkindahl do you think that is a better solution than removing the FK constraint? Perhaps we should do this directly in this PR?

@mkindahl
Copy link
Member

mkindahl commented Jun 4, 2025

We should probably use NULL to represent this, since NULL means "no association with the referenced table", which is essentially what "invalid hypertable" means.

@mkindahl do you think that is a better solution than removing the FK constraint? Perhaps we should do this directly in this PR?

IMHO; this is a better alternative since this is this is what the semantics is used for.

@erimatnor erimatnor force-pushed the remove-column-stats-fk branch from 2305074 to 0beed12 Compare June 5, 2025 12:21
@erimatnor erimatnor added this to the v2.20.3 milestone Jun 5, 2025
@erimatnor erimatnor force-pushed the remove-column-stats-fk branch 2 times, most recently from 6e856ec to 55817e3 Compare June 5, 2025 16:53
@erimatnor
Copy link
Member Author

@mkindahl @antekresic @fabriziomello I updated this PR to change the table schema to allow NULL values as some of you suggested. This is a bigger change than the quick fix I did first,, so I would appreciate if you could review one more time. I added some new update tests and it was a bit messy since not all tested versions support chunk skipping. Please check the update test changes to ensure I am doing sane things.

@erimatnor erimatnor force-pushed the remove-column-stats-fk branch 2 times, most recently from 3fd68b5 to a22af95 Compare June 9, 2025 07:03
Copy link
Member

@mkindahl mkindahl left a comment

Choose a reason for hiding this comment

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

Patch looks fine, but it would be good if we could make sure that the downgrade is truly restoring the old state.

@erimatnor erimatnor force-pushed the remove-column-stats-fk branch 2 times, most recently from 6cc618e to 7b060f9 Compare June 10, 2025 10:30
Copy link
Member

@mkindahl mkindahl left a comment

Choose a reason for hiding this comment

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

As we discussed, it was difficult to get it to work correctly through the downgrade with foreign keys intact, so approving the patch with the new warning since we expect downgrades to be rare.

We should probably consider removing foreign keys entirely in the catalog. After all, PostgreSQL does not use them, probably because it is hard to maintain them through catalog schema modifications.

@erimatnor erimatnor added the bug label Jun 10, 2025
@erimatnor erimatnor force-pushed the remove-column-stats-fk branch 2 times, most recently from f2475e4 to 7914fe3 Compare June 10, 2025 13:12
The net test started to fail due to a failure or change in the remote
endpoint `postman-echo.com`.

Also add the telemetry to the ignore list for the sanitizer tests
since it is in ignore in other tests.
The chunk skipping feature uses a "special" entry in the catalog table
chunk_column_stats to indicate that chunk skipping is enabled for that
column. The special entry has the chunk_id column set to 0. However,
at the same time the table schema defines a foreign key on the
chunk_id column where the 0 entry violates that constraint. This
prevents a dump/restore from working when such an entry is present.

To fix this issue, change the schema for chunk column stats to use
NULL instead of 0 for "chunk_id" to indicate the special
entry. Foreign keys work with such NULL entries so the foreign key can
remain.

Add an update test to ensure that pg_dump/pg_restore works properly.
@erimatnor erimatnor force-pushed the remove-column-stats-fk branch from 7914fe3 to fd474b0 Compare June 10, 2025 14:04
@erimatnor erimatnor enabled auto-merge (rebase) June 10, 2025 14:04
@erimatnor erimatnor merged commit 8a0a329 into timescale:main Jun 10, 2025
49 checks passed
@timescale-automation
Copy link
Member

Automated backport to 2.20.x not done: cherry-pick failed.

Git status

HEAD detached from origin/2.20.x
You are currently cherry-picking commit 8a0a32934.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   .unreleased/pr_8211
	modified:   scripts/test_update_from_version.sh
	modified:   scripts/test_updates.sh
	modified:   sql/pre_install/tables.sql
	modified:   src/ts_catalog/chunk_column_stats.c
	new file:   test/sql/updates/cleanup.chunk_skipping.sql
	modified:   test/sql/updates/cleanup.v7.sql
	new file:   test/sql/updates/cleanup.v8.sql
	new file:   test/sql/updates/cleanup.v9.sql
	new file:   test/sql/updates/post.chunk_skipping.sql
	new file:   test/sql/updates/post.v9.sql
	modified:   test/sql/updates/pre.cleanup.sql
	new file:   test/sql/updates/setup.chunk_skipping.sql
	new file:   test/sql/updates/setup.v9.sql
	modified:   tsl/test/expected/chunk_column_stats.out

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   sql/updates/latest-dev.sql
	both modified:   sql/updates/reverse-dev.sql


Job log

@timescale-automation timescale-automation added auto-backport-not-done Automated backport of this PR has failed non-retriably (e.g. conflicts) backported-2.20.x labels Jun 10, 2025
@philkra philkra mentioned this pull request Jun 11, 2025
philkra added a commit that referenced this pull request Jun 11, 2025
## 2.20.3 (2025-06-11)

This release contains bug fixes since the 2.20.2 release. We recommend
that you upgrade at the next available opportunity.

**Bugfixes**
* [#8107](#8107) Adjust
SkipScan cost for quals needing full scan of indexed data.
* [#8211](#8211) Fixed dump
and restore when chunk skipping is enabled.
* [#8216](#8216) Fix for
dropped quals bug in SkipScan.
* [#8230](#8230) Fix for
inserting into compressed data when a vectorized check is not available.
* [#8236](#8236) Fixed the
snapshot handling in background workers.

**Thanks**
* @ikaakkola for reporting that SkipScan is slow when non-index quals do
not match any tuples.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport-not-done Automated backport of this PR has failed non-retriably (e.g. conflicts) backported-2.20.x bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pg_restore: error: COPY failed for table "chunk_column_stats
5 participants