Re: Restoring using PG_DUMP in PG12 results in

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: "Shukla, Pranjal" <pshukla(at)akamai(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Restoring using PG_DUMP in PG12 results in
Date: 2022-03-15 15:49:57
Message-ID: e22df424-a054-3257-d338-1fd49506933f@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/14/22 23:42, Shukla, Pranjal wrote:
> Thanks Adrian,
> Can we say that, "Despite an informational Error, entire data got imported with sanity in the original case"?

Yes.
To verify see that the public schema is there and has tables and other
objects in it.

Also, can we say that either of the approaches mentioned i.e. Approach 1
& 2 are equally good to do migration from PG 10 to PG 12?

As I said before I could not understand what you did.

The best approach in your case is to:

1) Use the Postgres 12 version of pg_dump to dump the Postgres 10 server.
2) Use the Postgres 12 version of pg_restore to restore it to the
Postgres 12 server.

>
> Thanks & Regards
> Pranjal Shukla
>
> On 3/14/22, 8:25 PM, "Adrian Klaver" <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>
> On 3/14/22 06:39, Shukla, Pranjal wrote:
> > Hello,
> >
> > We tried importing into an empty database in PG 12 from the dump that
> > was created in PG 10. Import was successful but we got an message that
> > an error was ignored. We agin imported with -e option and the following
> > message was printed:
> >
> > pg_restore: while PROCESSING TOC:
> >
> > pg_restore: from TOC entry 6; 2615 2200 SCHEMA public postgres
> >
> > pg_restore: error: could not execute query: ERROR:schema "public"
> > already exists
>
> Basically an informational error that tells you that the restore was
> trying to create an object that already exists, in this case the pubic
> schema. Not really an issue.
> >
> > Command was: CREATE SCHEMA public;
> >
> > There are some blogs that ar pointing to that fact the error is because
> > of different versions of PG Admin Utility namely different versions of
> > pg_dump() and pg_resotre() command in source and destination versions.
> > We use the following command for pg_dump and pg_restore.
> >
>
> > 1. Have you faced this scenario?
> > 2. Off the approaches mentioned above, which one do you think we should
> > opt for while doing migration from PG 10 to 12 (in different machines)?
>
> Honestly I could not follow what you did. Best practice when moving from
> older version to newer version is to use the newer version's pg_dump
> against the older version and then use the newer versions pg_restore or
> psql(for text dumps) to restore.
>
> >
> > PS: Below is the command we use to create database:
> >
> > /CREATE DATABASE mydb WITH ENCODING 'UTF8' LC_COLLATE 'C' LC_CTYPE 'C'
> > TEMPLATE template0;/
> >
> > *Thanks & Regards*
> >
> > *Pranjal Shukla*
> >
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jorel Casal 2022-03-15 16:01:05 Corrupt Index
Previous Message Tom Lane 2022-03-15 14:32:07 Re: Re[2]: LISTEN/NOTIFY ultra slow speed