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
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 |