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

Re: pg_dump problem

From: Laura Del Caño <ldelcano(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump problem
Date: 2008-08-29 07:02:31
Message-ID: (view raw or whole thread)
Lists: pgsql-general
Sorry, I forgot to say I am using version 8.2.6.
I already removed option -n and left only -s (sincer there are no
other user schemas in the db) and I get the same error.

However when I removed the -c option it worked fine!

And also when using a formatted dump it works ok (even with -c option)
pg_dump -c -s -Ft -f backups/schema.tar syslog


On Thu, Aug 28, 2008 at 6:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "=?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:
> 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

pgsql-general by date

Next:From: Magnus HaganderDate: 2008-08-29 07:41:14
Subject: Re: MySQL LAST_INSERT_ID() to Postgres
Previous:From: Giorgio ValotiDate: 2008-08-29 06:39:54
Subject: [Semi-OT]: How to customize locales?

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