8 Commits

Author SHA1 Message Date
Fabrízio de Royes Mello
e84a6e2e65 Remove the refresh step from CAgg migration
We're facing some weird `portal snapshot` issues running the
`refresh_continuous_aggregate` procedure called from other procedures.

Fixed it by ignoring the Refresh Continuous Aggregate step from the
`cagg_migrate` and warning users to run it manually after the execution.

Fixes #4913
2022-11-22 16:49:13 -03:00
Fabrízio de Royes Mello
6ae192631e Fix CAgg migration with timestamp without timezone
It was a leftover from the original implementation where we didn't add
tests for time dimension using `timestamp without timezone`.

Fixed it by dealing with this datatype and added regression tests.

Fixes #4956
2022-11-11 15:25:01 -03:00
Fabrízio de Royes Mello
bfef3173bc Refactor CAgg migration code to use job API
The current implementation update the jobs table directly and to make it
consistent with other parts of the code we changed it to use the
`alter_job` API instead to enable and disable the jobs during the
migration. This refactoring is related to #4863.
2022-11-08 17:41:01 -03:00
Fabrízio de Royes Mello
6c73b61b99 Fix orphan jobs after CAgg migration
When using `override => true` the migration procedure rename the
current cagg using the suffix `_old` and rename the new created with
suffix `_new` to the original name.

The problem is the `copy polices` step was executed after the
`override` step and then we didn't found the new cagg name because it
was renamed to the the original name leading the policy orphan (without
connection with the materialization hypertable).

Fixed it by reordering the steps executin the `copy policies` before
the `override` step. Also made some ajustments to properly copy all
`bgw_job` columns even if this catalog table was changed.

Fixes #4885
2022-11-05 12:45:24 -03:00
Fabrízio de Royes Mello
7dd45cf348 Fix failure resuming a CAgg migration
Trying to resume a failed Continuous Aggregate raise an exception that
the migration plan already exists, but this is wrong and the expected
behaviour should be resume the migration and continue from the last
failed step.
2022-11-03 14:18:53 -03:00
Fabrízio de Royes Mello
893faf8a6b Fix Continuous Aggregate migration policies
After migrate a Continuous Aggregate from the old format to the new
using `cagg_migrate` procedure we end up with the following problems:
* Refresh policy is not copied from the OLD to the NEW cagg;
* Compression setting is not copied from the OLD to the NEW cagg.

Fixed it by properly copying the refresh policy and setting the
`timescaledb.compress=true` flag to the new CAGG.

Fix #4710
2022-09-22 17:38:21 -03:00
Fabrízio de Royes Mello
02ad4f6b76 Change parameter names of cagg_migrate procedure
Removed the underline character prefix '_' from the parameter names of
the procedure `cagg_migrate`. The new signature is:

cagg_migrate(
    IN cagg regclass,
    IN override boolean DEFAULT false,
    IN drop_old boolean DEFAULT false
)
2022-09-13 17:22:27 -03:00
Fabrízio de Royes Mello
e34218ce29 Migrate Continuous Aggregates to the new format
Timescale 2.7 released a new version of Continuous Aggregate (#4269)
that store the final aggregation state instead of the byte array of
the partial aggregate state, offering multiple opportunities of
optimizations as well a more compact form.

When upgrading to Timescale 2.7, new created Continuous Aggregates
are using the new format, but existing Continuous Aggregates keep
using the format they were defined with.

Created a procedure to upgrade existing Continuous Aggregates from
the old format to the new format, by calling a simple procedure:

test=# CALL cagg_migrate('conditions_summary_daily');

Closes #4424
2022-08-25 17:49:09 -03:00