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

pg_dump print error location

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: pg_dump print error location
Date: 2004-08-20 20:00:29
Message-ID: 200408202000.i7KK0Te10347@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Patch applied.  Thanks.

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


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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-08-20 20:07:33
Subject: Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE
Previous:From: Marc G. FournierDate: 2004-08-20 20:00:24
Subject: Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-08-20 20:07:33
Subject: Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE
Previous:From: Marc G. FournierDate: 2004-08-20 20:00:24
Subject: Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE

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