Fix dump/restore when chunk skipping is enabled #8211
Conversation
erimatnor
force-pushed
the
remove-column-stats-fk
branch
3 times, most recently
from
b91f94d to
f5efdaa
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8211 +/- ##
==========================================
+ Coverage 82.30% 82.36% +0.06%
==========================================
Files 256 256
Lines 48016 47988 -28
Branches 12113 12109 -4
==========================================
+ Hits 39518 39524 +6
- Misses 3638 3658 +20
+ Partials 4860 4806 -54 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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. As a temporary solution, remove the foreign key constraint. A longer term solution should probably use a different way to indicate that chunk skipping is enabled.
erimatnor
force-pushed
the
remove-column-stats-fk
branch
from
f5efdaa to
2305074
Compare
|
@gayyappan, @svenklemm: please review this pull request.
|
@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. |
| @@ -239,8 +239,8 @@ CREATE TABLE _timescaledb_catalog.chunk_column_stats ( | |||
| CONSTRAINT chunk_column_stats_pkey PRIMARY KEY (id), | |||
| CONSTRAINT chunk_column_stats_ht_id_chunk_id_colname_key UNIQUE (hypertable_id, chunk_id, column_name), | |||
| CONSTRAINT chunk_column_stats_range_check CHECK (range_start <= range_end), | |||
| CONSTRAINT chunk_column_stats_hypertable_id_fkey FOREIGN KEY (hypertable_id) REFERENCES _timescaledb_catalog.hypertable (id), | |||
| CONSTRAINT chunk_column_stats_chunk_id_fkey FOREIGN KEY (chunk_id) REFERENCES _timescaledb_catalog.chunk (id) | |||
| -- No FK for chunk_id since we allow entries with Invalid chunk ID (0) | |||
There was a problem hiding this comment.
Shouldn't it be NULL instead of 0 (zero)??
There was a problem hiding this comment.
Yeah, I am working on a version of the patch to test that.
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.
As a temporary solution, remove the foreign key constraint. A longer term solution should probably use a different way to indicate that chunk skipping is enabled.
Fixes: #8130