Skip site navigation (1) Skip section navigation (2)

Re: pg_dump problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laura Del Caño <ldelcano(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump problem
Date: 2008-08-28 16:07:05
Message-ID: 12446.1219939625@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
"=?ISO-8859-1?Q?Laura_Del_Ca=F1o?=" <ldelcano(at)gmail(dot)com> writes:
> I am issuing the following command:
> pg_dump -c -o -s -n distributed -f backups/schema.sql syslog
> which apparently works fine. It is only when I tried to restore it in
> a fresh created database using:
> psql syslog < backups/schema.sql
> that I get lots of errors saying objects do not exist.

> Having a look at the schema.sql file I see the following:

> SET search_path = distributed, pg_catalog;
> ...
> CREATE SCHEMA distributed;

Is that SET located before/during the sequence of DROPs issued due to -c ?

I think this is a known bug in the behavior of -c.  It was fixed before
8.3 release but doesn't seem to have been back-patched into any older
branches:

http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_archiver.c.diff?r1=text&tr1=1.149&r2=text&tr2=1.151

Simplest workaround with older pg_dumps might be to avoid -c and
just do a manual "DROP SCHEMA distributed CASCADE" before restoring
the dump.

			regards, tom lane

In response to

Responses

pgsql-general by date

Next:From: Masis, Alexander (US SSA)Date: 2008-08-28 16:14:59
Subject: MySQL LAST_INSERT_ID() to Postgres
Previous:From: Bill MoranDate: 2008-08-28 16:04:36
Subject: Re: Vaccuum best practice: cronjob or autovaccuum?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group