Re: pg_restore issue - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_restore issue
Date
Msg-id 32677.1392231881@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_restore issue  (Leonardo M. Ramé <l.rame@griensu.com>)
Responses Re: pg_restore issue
List pgsql-general
Leonardo =?iso-8859-1?Q?M=2E_Ram=E9?= <l.rame@griensu.com> writes:
> On 2014-02-12 13:30:52 -0500, Tom Lane wrote:
>> The -c switch causes pg_restore to try to DROP every object it's about to
>> restore.  If you're restoring into an empty database then this is useless,
>> and in fact will not work if you're also using --exit-on-error.  Remove
>> one or the other switch.

> Tom, I've dropped the db, then createdb again, then removed the -c
> option, now I get this error:

> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 735; 2612 213488
> PROCEDURAL LANGUAGE plpgsql postgres
> pg_restore: [archiver (db)] could not execute query: ERROR:  language
> "plpgsql" already exists
>     Command was: CREATE PROCEDURAL LANGUAGE plpgsql;

pg_dump versions more recent than 8.4 use "CREATE OR REPLACE PROCEDURAL
LANGUAGE" to work around the possibility that plpgsql is preinstalled.
If you don't want to use a modern pg_dump, you'll need to not use
--exit-on-error.

In general, it's recommended to use the newer pg_dump when trying to
transfer data from an older installation to a newer one.  You can
generally make it work without that, but it's not necessarily going
to be seamless, and one of the ways it tends to not be seamless is
that you have to be willing to ignore harmless errors.

            regards, tom lane


pgsql-general by date:

Previous
From: Leonardo M. Ramé
Date:
Subject: Re: pg_restore issue
Next
From: Leonardo M. Ramé
Date:
Subject: Re: pg_restore issue