Simon Riggs <simon@2ndQuadrant.com> writes:
> libpq updates are much harder to roll out, so it would be better to
> assume that it is correct and the backend is wrong if we want to
> backpatch the fix.
I don't think that's a particularly sound argument.
If we view this as a protocol definitional issue, which it is, then
changing the backend means that we're changing the protocol and thus
that the changes might impact other clients besides libpq. Now,
it's quite possible that libpq is the only client-side code that's
supporting COPY BOTH mode at all ... but we don't know that do we?
Also, I think that expecting the backend to do something else
after throwing an error is probably doomed to failure --- consider
the case where what it's sending is a FATAL ereport about a SIGTERM
interrupt, for example. It's not going to be hanging around to
clean up any bidirectional copies.
So I'm inclined to think that Robert's patch is headed in the right
direction, though I've not tried to review the changes in detail.
regards, tom lane