Обсуждение: What to do with tablespaces when upgrading to pg13 from pg1X?
Hello,
I was planning to upgrade from 12 to 13 using this command:
/usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin/ -B /usr/pgsql-13/bin/ -d /data/pg/ -D /pg/pgdata_13/ --jobs=10
And I got this output:
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
new cluster tablespace directory already exists: "/data/tsdb/metas/PG_13_202007201"
Failure, exiting
I think it's because /data/tsdb was my tablespace dir which was out of the old main data directory(/data/pg/).
So what should I do with old tablespaces when upgrading ?
Thanks a lot !
On Tue, Jan 12, 2021 at 10:28:52AM +0800, James(王旭) wrote: > Hello, > I was planning to upgrade from 12 to 13 using this command: > > /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin/ -B /usr/pgsql-13/bin/ -d > /data/pg/ -D /pg/pgdata_13/ --jobs=10 > > > And I got this output: > > 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 > new cluster tablespace directory already exists: "/data/tsdb/metas/ > PG_13_202007201" > Failure, exiting > > I think it's because /data/tsdb was my tablespace dir which was out of the old > main data directory(/data/pg/). > > So what should I do with old tablespaces when upgrading ? There should be a subdirectory under your tablespace directory for every major version, e.g., PG_13_202007201. I have no idea why your _new_ version already has a directory there. Do you have a second cluster on the machine that is using that tablespace directory for PG 13? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
You mean PG_13_202007201 was created by PG 13 ? No, there isn't any other clusters, maybe it was created by my previous failed attempts of upgrading.
So it seems it should be ok that I issue a command like this
find . -name "PG_13*"|xargs rm -rf
and then do upgrade again?
There should be a subdirectory under your tablespace directory for every
major version, e.g., PG_13_202007201. I have no idea why your _new_
version already has a directory there. Do you have a second cluster on
the machine that is using that tablespace directory for PG 13?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
major version, e.g., PG_13_202007201. I have no idea why your _new_
version already has a directory there. Do you have a second cluster on
the machine that is using that tablespace directory for PG 13?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Tue, Jan 12, 2021 at 10:50:16AM +0800, James(王旭) wrote: > You mean PG_13_202007201 was created by PG 13 ? No, there isn't any other > clusters, maybe it was created by my previous failed attempts of upgrading. Yes, it had to be created by PG 13 --- it starts with PG_13, followed by the system catalog version. Yes, it might be left over. You have to delete the old cluster and its tablespaces when you re-try. > So it seems it should be ok that I issue a command like this > > find . -name "PG_13*"|xargs rm -rf > > and then do upgrade again? I suggest you do more research than just run that --- at least I would. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Got you, thanks a lot Bruce!
------------------ Original ------------------
From: "Bruce Momjian"<bruce@momjian.us>;
Date: Tue, Jan 12, 2021 11:01 AM
To: "James(王旭)"<wangxu@gu360.com>;
Cc: "pgsql-general"<pgsql-general@postgresql.org>;
Subject: Re: What to do with tablespaces when upgrading to pg13 from pg1X?
On Tue, Jan 12, 2021 at 10:50:16AM +0800, James(王旭) wrote:
> You mean PG_13_202007201 was created by PG 13 ? No, there isn't any other
> clusters, maybe it was created by my previous failed attempts of upgrading.
Yes, it had to be created by PG 13 --- it starts with PG_13, followed by
the system catalog version. Yes, it might be left over. You have to
delete the old cluster and its tablespaces when you re-try.
> So it seems it should be ok that I issue a command like this
>
> find . -name "PG_13*"|xargs rm -rf
>
> and then do upgrade again?
I suggest you do more research than just run that --- at least I would.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
> You mean PG_13_202007201 was created by PG 13 ? No, there isn't any other
> clusters, maybe it was created by my previous failed attempts of upgrading.
Yes, it had to be created by PG 13 --- it starts with PG_13, followed by
the system catalog version. Yes, it might be left over. You have to
delete the old cluster and its tablespaces when you re-try.
> So it seems it should be ok that I issue a command like this
>
> find . -name "PG_13*"|xargs rm -rf
>
> and then do upgrade again?
I suggest you do more research than just run that --- at least I would.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee