Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers