Re: pg_dump 'die_on_errors'
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump 'die_on_errors' |
Дата | |
Msg-id | 200408120327.i7C3RET14138@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump 'die_on_errors' (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump 'die_on_errors'
|
Список | 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 по дате отправления: