-
Notifications
You must be signed in to change notification settings - Fork 884
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
[Bug]: cagg_migrate() does not work on caggs that have a time_bucket column with an interval added as offset #7236
Comments
Digging a bit further into this, by looking at how cagg_migrate.sql works and what different queries used in the script return when querying tables from the different _timescaledb schemas. Creating two caggs where one has the offset and one does not:
This produces two different materialized_hypertable tables in the _timescaledb_internal schema: WITH offset:
WITHOUT offset:
Then querying
Of which the
When looking at the I imagine that timescaledb puts information about the caggs into the |
@Streamlinesx Thank you for the bug report, this indeed looks like a bug. |
Hi @mkindahl , thanks for acknowledging the bug. @fabriziomello is this a possible fix? Replace at line 163 in cagg_migrate.sql
|
@fabriziomello I have continued development on this issue and found a way that works for our specific database structure, but I believe it is possible to work with the ideas and form them into a generic fix by adding the space dimension identifier if present to join tables in the copy_data procedure. I had to work on two procedures: The cagg_migrate_create_plan procedure and the cagg_migrate_execute_copy_data procedure. Both were having issues with the 'time_partition_col'. The modifications to the cagg_migrate_create_plan procedure should be generic, but the modifications in the cagg_migrate_execute_copy_data are not. Also while testing my solution I always had to manually add the column 'user_view_definition' of type 'text' to the _timescaledb_catalog.continuous_agg_migrate_plan table after bringing up a fresh container with tsdb version 2.9.3 and PG12. This column is important for the copy_data procedure.
|
@Streamlinesx Looks like you're on the way to fix it. :) If you have a proposal for a fix, do not hesitate to submit a pull request and we can do a proper review of it and suggest improvements and find problems. |
@mkindahl for our specific database I have fixed it and I was able to migrate the affected caggs to the new format without issue with the above modifications. However, with the modifications it will not work with caggs that do not have an offset anymore, so during the migration I had to migrate the non-offset caggs first, then modify the procedures, and then migrate the offset caggs. I have an idea for how I could make the fix more generic, but I don't think I will have time to spend on it. Maybe I'll get to it in my private time since it does interest me and I feel like I have a good understanding of the situation. |
What type of bug is this?
Unexpected error
What subsystems and features are affected?
Other
What happened?
What happened:
I tried to migrate our caggs to the 'new' format from the 'old' format. However when trying to execute the cagg_migrate() function on the affected cagg, it throws an error saying it cannot find the time_partition_col
This prevents us from updating our database to the most recent version without losing data and we are stuck using PG12
What is expected to happen:
The cagg_migrate() to execute successfully and migrate the cagg
TimescaleDB version affected
2.9.3
PostgreSQL version used
12
What operating system did you use?
Windows 10 x64
What installation method did you use?
Docker
What platform did you run on?
Not applicable
Relevant log output and stack trace
How can we reproduce the bug?
The text was updated successfully, but these errors were encountered: