From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "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 10:02:58 |
Message-ID: | CA+U5nM+OcC_AV5-_1D9AWXju9KAfMJ9VYApMrcJwzEbFF6nNPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 April 2013 03:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> It seems the backend and libpq don't agree. The backend makes no
> special provision to wait for a CopyDone message if an error occurs
> during copy-both. It simply sends an ErrorResponse and that's it.
> libpq, on the other hand, treats either CopyDone or ErrorResponse as a
> cue to transition to PGASYNC_COPY_IN (see pqGetCopyData3).
Well spotted, and good detective work.
> I'm attaching a patch which adopts the position that the backend is
> right and libpq is wrong. The opposite approach is also possible, but
> I haven't tried to implement it. Or maybe there's a third way which
> is better still.
I guess if we assume this only affects replication we could change it
at either end, not sure about that.
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.
Not sure if that is a lot of work?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-04-27 14:59:32 | Remaining beta blockers |
Previous Message | Tom Lane | 2013-04-27 04:26:28 | Re: Assert's vs elog ERROR vs elog FATAL |