Add workaround for downgrade in 2.22.0 #48
Conversation
Downgrading from 2.22.0 is blocked in certain cases due to unrefreshed CAggs. This provides a workaround, if CAggs cannot be refreshed before downgrading.
| ORDER BY sr.materialization_id | ||
| LOOP | ||
| RAISE NOTICE 'force refreshing %s: start:%s end:%s', range_record.cagg_name, _timescaledb_functions.to_timestamp(range_record.lowest), _timescaledb_functions.to_timestamp(range_record.greatest); | ||
| CALL refresh_continuous_aggregate(range_record.cagg_name, _timescaledb_functions.to_timestamp(range_record.lowest), _timescaledb_functions.to_timestamp(range_record.greatest), force => true); |
There was a problem hiding this comment.
You should also consider integer time dimension
| END LOOP; | ||
| END $$; | ||
|
|
||
| DROP TABLE _timescaledb_internal.saved_ranges; |
There was a problem hiding this comment.
| END LOOP; | |
| END $$; | |
| DROP TABLE _timescaledb_internal.saved_ranges; | |
| END LOOP; | |
| DROP TABLE _timescaledb_internal.saved_ranges; | |
| END $$; |
I think it must be part of the anonymous transaction.
| DO $$ | ||
| DECLARE | ||
| range_record RECORD; | ||
| BEGIN |
There was a problem hiding this comment.
Maybe here you can check for the existance of the stating table and raise an exception that the table don't exists so probably the script was already executed.
| SELECT * | ||
| INTO _timescaledb_internal.saved_ranges | ||
| FROM _timescaledb_catalog.continuous_aggs_materialization_ranges; |
There was a problem hiding this comment.
| SELECT * | |
| INTO _timescaledb_internal.saved_ranges | |
| FROM _timescaledb_catalog.continuous_aggs_materialization_ranges; | |
| CREATE TABLE _timescaledb_internal.saved_ranges AS | |
| SELECT * | |
| FROM _timescaledb_catalog.continuous_aggs_materialization_ranges | |
| ORDER BY materialization_id, lowest_modified_value; |
Nit. IMHO using CREATE TABLE instead of SELECT INTO express better the intention.
| \set ON_ERROR_STOP ON | ||
|
|
||
| SELECT * | ||
| INTO _timescaledb_internal.saved_ranges |
There was a problem hiding this comment.
Also maybe continuous_aggs_materialization_ranges_before_downgrade_2_22_0 can be a better name to also express the intention.
I think it should be saved it in the public schema instead cause is preferred to let the extension update/downgrade script mess with our internal schemas.
Downgrading from 2.22.0 is blocked in certain cases due to unrefreshed CAggs. This provides a workaround, if CAggs cannot be refreshed before downgrading.