In timescale#6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes timescale#6935

In timescale#6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes timescale#6935

In timescale#6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes timescale#6935

In timescale#6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes timescale#6935

In timescale#6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes timescale#6935

In #6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes #6935

In #6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes #6935

(cherry picked from commit 8b994c7)

In #6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes #6935

(cherry picked from commit 8b994c7)

In #6624 we refactored the time bucket catalog table to make it more
generic and save information for all Continuous Aggregates. Previously
it stored only variable bucket size information.

The problem is we used the `regprocedure` type to store the OID of the
given time bucket function but unfortunately it is not supported by
`pg_upgrade`.

Fixed it by changing the column to TEXT and resolve to/from OID using
builtin `regprocedurein` and `format_procedure_qualified` functions.

Fixes #6935

(cherry picked from commit 8b994c7)

It's long since we need to have binary upgrade tests in our CI. One
example is the timescale#6935 (and others) that can be prevented if we have such
kind of test in our CI.

To implement th `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a sucessful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement th `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a sucessful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement th `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement th `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is timescale#6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes timescale#3868 timescale#4428

It's long we need to have binary upgrade tests in our CI. One example
is #6935 (and others) that can be prevented if we have such kind of
test in our CI.

To implement the `pg_upgrade` test we used the python Testing Framework
for PostgreSQL (https://github.com/postgrespro/testgres).

Unfortunately the testing framework don't have the ability to retain the
pg_upgrade log files after a successful execution, then we created a PR
to make it possible and we'll use this patched version until we get the
code merged and released on upstream.

postgrespro/testgres#125

Closes #3868 #4428