Re: pg_dump 'die_on_errors' - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_dump 'die_on_errors'
Date
Msg-id 200408120327.i7C3RET14138@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_dump 'die_on_errors'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump 'die_on_errors'
List pgsql-hackers
Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > At 02:31 AM 12/08/2004, Tom Lane wrote:
> >> result of
> >> considerable experience that says die_on_errors is NOT the right
> >> behavior for pg_restore.
> 
> > Can you point me to examples?
> 
> Trawl the archives for pg_restore complaints ... but basically the point
> is that if you fail to restore object N, that doesn't mean you should
> refuse to even try to restore the objects after it.  A typical example
> is that ALTER OWNER TO fails because the original owner doesn't exist in
> the new DB.  There is no reason here not to keep plugging.  If you
> abort, the user will have to erase the DB, add the user (whether he
> wants to or not, and whether he has the privileges to or not), and start
> over.  If you don't abort, the worst case is that he has to do exactly
> that anyway; but he may not care, and even if he does care it may be a
> lot faster to fix things by hand afterwards.
> 
> It probably would be a good idea to try to fix things to make the
> restore operation less noisy (eg, ditch all the NOTICEs about creating
> indexes) so that people could see the actual errors more easily.  That's
> not at all the same thing as putting in die-on-error, though.

Set client_min_messages to WARNING?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dollar-quoting in psql and in general
Next
From: Tom Lane
Date:
Subject: Re: dollar-quoting in psql and in general