On Fri, 16 Jul 2010, Kris Jurka wrote:
> That seems likely. What's probably necessary to reproduce this is a
> failure at the end of the data stream. An early error will be received
> and processed normally, but an error at the end will be buffered and the
> driver will think everything succeeded and try to end the copy not
> knowing that it has already failed. I think we'd need to call the
> blocking version of processCopyResults prior to endCopy to avoid this
> misleading error.
>
Actually with a little more thinking, what I said was completely bogus.
1) Blocking won't fix anything because in the success path, there's no
message to receive, so there's nothing to process.
2) The protocol docs say that after an error, CopyData,
CopyDone, and CopyFail messages are ignored, so they wouldn't be causing
this error.
So some more thought is needed here...
Kris Jurka