Jeff Davis <pgsql@j-davis.com> writes:
> On Thu, 2011-04-14 at 10:50 +0300, Heikki Linnakangas wrote:
>> I think you'll need to send all the data and finish the COPY until you
>> get an error. If you have a lot of data to send, you might want to slice
>> it into multiple COPY statements of say 50MB each, so that you can catch
>> errors in between.
> If the remaining CopyData messages are dropped, I don't see why
> PQputCopyData can't return some kind of error indicating that further
> CopyData messages are useless so that it can stop sending them.
An error from PQputCopyData indicates a connection-level problem,
typically; that is it means that it couldn't send data not that the server
had detected a problem with some earlier data. I'd not be surprised
if applications would respond to such an error indication by just
pre-emptively dropping the connection. (A quick trawl through our
own code shows a precedent in pg_restore, in fact.) So the idea
of having PQputCopyData start failing as soon as an error has arrived
from the server doesn't sound that attractive.
What'd be safer is to provide a way of detecting whether an error
has arrived (without actually consuming it, of course) so that the
case could be handled by adding something like
if (PQerrorIsPending(conn)) break;
to the send-data loop. This would allow the application code to know
what is happening. It would also not impose the penalty of checking
for errors on apps that prefer to optimize for the no-error case.
A different approach would be for PQputCopyData to just internally
suppress sending of further CopyData messages, *without* returning
an error; this would be transparent and it would save the network
traffic at least. However, my reading of the original example is
that the OP was at least as interested in suppressing the creation
of further data as in suppressing the sending, so this wouldn't
really solve his problem completely. And it's also optimizing
for the error case not the no-error case, in a way that doesn't give
the app any say in the matter. So I'm not for this particularly,
just mentioning it for completeness.
regards, tom lane
