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 22:12:24
Message-ID: CA+U5nMLwnA=YRYMzLiH35OmaNcCqqETTNTZh5=hrkduy8EUqxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 April 2013 20:12, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> My feeling is that it would be better not to back-patch this, but just
> fix it in master. Given the present uses of COPY-BOTH mode, the
> problems seem to be limited to bad error messages, so it's arguably
> not a critical bug fix. Also, I think that no matter which way we fix
> it, people who upgrade the master to a new point release, but not
> pg_receivexlog, would in some unlikely cases actually experience a
> regression in the quality of error messages. I would say we have to
> live with that if the consequences were any worse than bad error
> messages in the first place, but as far as I can tell they're not. If
> someone can contrive a scenario where this causes outright breakage,
> that would tip the balance for me, but I don't at present see such a
> hazard.
>
> On a practical level, the main thing I didn't like about trying to fix
> the server was the same issue that Tom mentioned: we'd need code in
> the server to track whether COPY-BOTH mode is active and skip client
> messages until we hit a CopyDone or CopyFail message. And I suspect
> that code would be somewhat fragile, because having sent an
> ErrorResponse already, we'd have no straightforward way to report a
> further error - we'd need to report follow-on errors via NOTICE or
> FATAL. Now this is not a disaster, but it's not great, either,
> because there's a lot of code (including, notably, palloc) which
> assumes that it can throw an ERROR whenever it likes. And in this
> case, it couldn't.
>
> The second thing I didn't like about that approach was that it would
> make COPY-BOTH quite asymmetrical with both COPY-OUT and COPY-IN.
> That didn't seem like a great idea, either.
>
> A further point is that the problems in the back branches are less
> serious anyway, because the timeline-switching code is the only thing
> that ever tries to exit COPY-BOTH mode without closing the connection,
> and that's new in 9.3.
>
> So for all those reasons, my vote is for a client-side, master-only fix.

+1, very sound

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-04-27 22:55:10 Re: [HACKERS] pgsql: Add sql_drop event for event triggers
Previous Message Tom Lane 2013-04-27 22:08:20 Re: strange warning sign relating to storage manager