Re: pg_dump 'die_on_errors'

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_dump 'die_on_errors'
Date: 2004-08-19 01:54:02
Message-ID: 200408190154.i7J1s2O04106@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Philip Warner wrote:
> At 01:32 AM 16/08/2004, Tom Lane wrote:
> >It'd be substantially *more* helpful if it reported the failing command.
>
> They are two different problems; the TOC entry is important for any
> multiline command or to rerun the command easily later.
>
> Whereas displaying the failed SQL command is a matter of fixing the error
> messages.
>
> The latter is complicated by failed COPY commands which, with die-on-errors
> off, results in the data being processed as a command, so dumping the
> command will dump all of the data.
>
> In the case of long commands, should the whole command be dumped? eg. (eg.
> several pages of function definition).
>
> In the case of the COPY command, I'm not sure what to do. Obviously, it
> would be best to avoid sending the data, but the data and command are
> combined (from memory). Also, the 'data' may be in the form of INSERT
> statements.
>
> Attached patch produces the first 125 chars of the command:
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC Entry 26; 1255 16449270 FUNCTION
> plpgsql_call_handler() pjw
> pg_restore: [archiver (db)] could not execute query: ERROR: function
> "plpgsql_call_handler" already exists with same argument types
> Command was: CREATE FUNCTION plpgsql_call_handler() RETURNS
> language_handler
> AS '/var/lib/pgsql-8.0b1/lib/plpgsql', 'plpgsql_call_han...
> pg_restore: [archiver (db)] Error from TOC Entry 27; 1255 16449271 FUNCTION
> plpgsql_validator(oid) pjw
> pg_restore: [archiver (db)] could not execute query: ERROR: function
> "plpgsql_validator" already exists with same argument types
> Command was: CREATE FUNCTION plpgsql_validator(oid) RETURNS void
> AS '/var/lib/pgsql-8.0b1/lib/plpgsql', 'plpgsql_validator'
> LANGU...
>
>
>
>
>
> ----------------------------------------------------------------
> Philip Warner | __---_____
> Albatross Consulting Pty. Ltd. |----/ - \
> (A.B.N. 75 008 659 498) | /(@) ______---_
> Tel: (+61) 0500 83 82 81 | _________ \
> Fax: (+61) 03 5330 3172 | ___________ |
> Http://www.rhyme.com.au | / \|
> | --________--
> PGP key available upon request, | /
> and from pgp.mit.edu:11371 |/

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-08-19 02:02:49 Re: PGPASSWORD and client tools
Previous Message Tom Lane 2004-08-19 01:42:37 Re: PGPASSWORD and client tools

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2004-08-19 02:02:49 Re: PGPASSWORD and client tools
Previous Message Tom Lane 2004-08-19 01:42:37 Re: PGPASSWORD and client tools