Re: exactly what is COPY BOTH mode supposed to do in case of an error?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: exactly what is COPY BOTH mode supposed to do in case of an error?
Date: 2013-04-27 15:11:38
Message-ID: 9549.1367075498@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-04-27 17:23:47 Re: Remaining beta blockers
Previous Message Tom Lane 2013-04-27 14:59:32 Remaining beta blockers