Re: pg_restore COPY error handling

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-patches(at)postgresql(dot)org
Subject: Re: pg_restore COPY error handling
Date: 2006-02-02 02:18:54
Message-ID: 20060202021854.GP4474@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> Tom Lane said:
> > 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.
>
> Could we not refrain from sending data if we detect that we are not in copy
> in state?

You have to know at that level if it's data you're getting or an SQL
statement though. SQL statements can fail and things move along
happily. Essentially what my patch does is detect when a COPY command
fails and then circular-file the data that comes in after it from the
upper-level. When I started to look at the way pg_restore worked I had
initially thought I could make the higher-level code realize that the
COPY command failed through a return-code and have it not pass the data
down but the return codes didn't appear to be very well defined to
handle that kind of communication... (As in, it looked like trying to
make that happen would break other things), I can look at it again
though.

Thanks,

Stephen

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-02-02 02:24:19 Re: TODO-Item: B-tree fillfactor control
Previous Message Stephen Frost 2006-02-02 02:11:48 Re: pg_restore COPY error handling