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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-patches by date

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