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

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

In response to

Responses

Browse pgsql-hackers by date

  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