-
Notifications
You must be signed in to change notification settings - Fork 849
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
Using regprocedure
blocks pg_upgrade
from doing a major PostgreSQL upgrade
#6935
Milestone
Comments
fabriziomello
added
bug
upgrade
Issue is related to upgrading the extension or the PostgreSQL version.
labels
May 20, 2024
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 21, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 21, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 21, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 21, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 22, 2024
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
fabriziomello
added a commit
that referenced
this issue
May 22, 2024
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
github-actions bot
pushed a commit
that referenced
this issue
May 22, 2024
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)
fabriziomello
added a commit
that referenced
this issue
May 22, 2024
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)
fabriziomello
added a commit
that referenced
this issue
May 22, 2024
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)
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 24, 2024
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
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this issue
May 25, 2024
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
fabriziomello
added a commit
that referenced
this issue
May 26, 2024
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
timescaledb/sql/pre_install/tables.sql
Line 354 in f7255f0
In the docs:
https://www.postgresql.org/docs/current/pgupgrade.html
This in turn causes major upgrades to fail with this error message:
The text was updated successfully, but these errors were encountered: