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

Re: BUG #4127: pg_dumpall -c unable to be restored without error

From: Jacob Champlin <jacobc(at)rentec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4127: pg_dumpall -c unable to be restored without error
Date: 2008-04-24 17:04:43
Message-ID: 4810BDAB.5060404@rentec.com (view raw or flat)
Thread:
Lists: pgsql-bugs
And if this is expected correct behavior it shouldn't throw an error....

This is especially problematic for automated processes, in which you 
only want to know when they fail.

Its possible to ignore error messages, but then when something real does 
go wrong you lose those.

Don't get me wrong I know this is not the end of the world, but I also 
think its the wrong behavior, one that is problematic for me.

Jacob

Tom Lane wrote:
> "Jacob Champlin" <jacobc(at)rentec(dot)com> writes:
>   
>> psql -f restore.sql
>>     
>
>   
>> results in:
>>     
>
>   
>> psql:/var/lib/pgsql/backups/restore.sql:11: ERROR:  current user cannot be
>> dropped
>> psql:/var/lib/pgsql/backups/restore.sql:12: ERROR:  role "postgres" already
>> exists
>> psql:/var/lib/pgsql/backups/restore.sql:17: ERROR:  role "webapp" cannot be
>> dropped because some objects depend on it
>> DETAIL:  access to database rief
>> 113 objects in database rief
>> psql:/var/lib/pgsql/backups/restore.sql:18: ERROR:  role "webapp" already
>> exists
>>     
>
> And?  The restore would've proceeded anyway.
>
> 			regards, tom lane
>
>   


In response to

pgsql-bugs by date

Next:From: Gary Jay PetersDate: 2008-04-24 18:19:44
Subject: BUG #4128: The postmaster.opts.default file is begin ignored
Previous:From: Tom LaneDate: 2008-04-24 16:44:14
Subject: Re: BUG #4127: pg_dumpall -c unable to be restored without error

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