Thread: [Major version upgrade] pg_upgrade fails despite passing check mode
While upgrading from Postgres 11 to 13, the pg_upgrade passed the check mode
postgres@dxxxpgs03:/Dxxxx1/datadg/data13$ /usr/pgsql-13/bin/pg_upgrade -k --check --new-datadir='/Dxxxx1/datadg/data13' --old-datadir='/Dxxxx1/datadg/data' --new-bind$
r='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin'
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*
But then while performing the actual upgrade, it failed saying the "owner of a FDW should be a super user"
So I started the old Postgres 11 again, changed the owner of that FDW to a super user.
Now when I try to run the upgrade (even in check mode) again, it says "new cluster tablespace directory already exists"
Is it safe to delete the new tablespace directories?
What are my options to safely start/upgrade the DB without any chances of data corruption?
r='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin'
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for tables WITH OIDS ok
Checking for invalid "sql_identifier" user columns ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*
But then while performing the actual upgrade, it failed saying the "owner of a FDW should be a super user"
So I started the old Postgres 11 again, changed the owner of that FDW to a super user.
Now when I try to run the upgrade (even in check mode) again, it says "new cluster tablespace directory already exists"
Is it safe to delete the new tablespace directories?
What are my options to safely start/upgrade the DB without any chances of data corruption?
Thanks
This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).
Thanks, let me try that out.
But is there a way to know for sure if pg_upgrade will have any such problems?
Other than FDW's owner, any other things I should check before upgrading other clusters?
Regards
Abhishek Bhola
On Sat, Oct 23, 2021 at 12:20 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Fri, 2021-10-22 at 17:11 +0900, Abhishek Bhola wrote:
> postgres@dxxxpgs03:/Dxxxx1/datadg/data13$ /usr/pgsql-13/bin/pg_upgrade -k --check
> --new-datadir='/Dxxxx1/datadg/data13' --old-datadir='/Dxxxx1/datadg/data'
> --new-bindir='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin'
>
> *Clusters are compatible*
>
> But then while performing the actual upgrade, it failed saying the "owner of a FDW should be a super user"
>
> So I started the old Postgres 11 again, changed the owner of that FDW to a super user.
>
> Now when I try to run the upgrade (even in check mode) again, it says "new cluster tablespace directory already exists"
>
> Is it safe to delete the new tablespace directories?
Don't remove the tablespace directories, because they contain the original data from the
old cluster. But there should be directories called PG_13_202007201, and you have to
remove those.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
This correspondence (including any attachments) is for the intended recipient(s) only. It may contain confidential or privileged information or both. No confidentiality or privilege is waived or lost by any mis-transmission. If you receive this correspondence by mistake, please contact the sender immediately, delete this correspondence (and all attachments) and destroy any hard copies. You must not use, disclose, copy, distribute or rely on any part of this correspondence (including any attachments) if you are not the intended recipient(s).
On Mon, Oct 25, 2021 at 07:52:13AM +0900, Abhishek Bhola wrote: > Thanks, let me try that out. > > But is there a way to know for sure if pg_upgrade will have any such problems? > Other than FDW's owner, any other things I should check before upgrading other > clusters? No. pg_upgrade's check mode checks as much as it reasonable can, but it doesn't try restoring the database schema, for performance reasons, and that is where the failure is happening. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.