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

Re: pg_restore COPY error handling

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_restore COPY error handling
Date: 2006-02-02 02:03:48
Message-ID: 7360.1138845828@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> This is not super surprising because the original design approach for
>> pg_restore was "bomb out on any sort of difficulty whatsoever".  That
>> was justly complained about, and now it will try to keep going after
>> SQL-command errors ... but it sounds like the COPY-data processing
>> part didn't get fixed properly.

> Exactly so.  Possibly because it appears to be non-trivial to detect
> when it was a *COPY* command which failed (to differentiate it from some
> other command).  What I did was check for '<whitespace>COPY'.  I'd be
> happy to change that if anyone has a better suggestion though.

ISTM you should be depending on the archive structure: at some level,
at least, pg_restore knows darn well whether it is dealing with table
data or SQL commands.

Also, it might be possible to depend on whether libpq has entered the
"copy in" state.  I'm not sure this works very well, because if there's
an error in the COPY command itself (not in the following data) then we
probably don't ever get into "copy in" state.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Stephen FrostDate: 2006-02-02 02:11:48
Subject: Re: pg_restore COPY error handling
Previous:From: Tom LaneDate: 2006-02-02 01:59:37
Subject: Re: TODO-Item: B-tree fillfactor control

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