Обсуждение: Re: [COMMITTERS] pgsql: Fix an ancient oversight in libpq's handling of V3-protocol COPY

Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2008-01-14 at 18:46 +0000, Tom Lane wrote:
>> Fix an ancient oversight in libpq's handling of V3-protocol COPY OUT mode:
>> we need to be able to swallow NOTICE messages, and potentially also
>> ParameterStatus messages (although the latter would be a bit weird),
>> without exiting COPY OUT state.  Fix it, and adjust the protocol documentation
>> to emphasize the need for this.  Per off-list report from Alexander Galler.

> My reading of this is that previously a PQgetCopyData() operation would
> fail mysteriously because of 

> i) a reload of postgresql.conf, following the setting of any of the
> following parameters client_encoding, DateStyle, TimeZone, and
> standard_conforming_strings.

> ii) any previous LISTEN command on the session running the COPY

Neither of those events could trigger it, because neither would be
processed midstream during a COPY (in the current code, anyway).
As best I can tell:

* NOTICE messages are a risk, especially if you have a more-verbose-
than-normal client_min_messages setting.

* ParameterStatus could be a risk if a function executed during COPY
tried to change one of the above-mentioned parameters.  Since COPY OUT
doesn't fire triggers, I think user-defined datatype output functions
would be the only possible candidates for that.

* LISTEN/NOTIFY isn't a risk because the backend only sends NOTIFY at
transaction end, period.
        regards, tom lane

I wrote:
> * ParameterStatus could be a risk if a function executed during COPY
> tried to change one of the above-mentioned parameters.  Since COPY OUT
> doesn't fire triggers, I think user-defined datatype output functions
> would be the only possible candidates for that.

Scratch that --- that thinking is so last-year :-(.  COPY OUT from a
SELECT subquery could fire any old function.  pg_dump isn't at risk
from that, but other applications would be.
        regards, tom lane

On Tue, 2008-01-15 at 16:37 -0500, Tom Lane wrote:

> Neither of those events could trigger it, because neither would be
> processed midstream during a COPY (in the current code, anyway).

OK, thanks.

> As best I can tell:
> 
> * NOTICE messages are a risk, especially if you have a more-verbose-
> than-normal client_min_messages setting.
> 
> * ParameterStatus could be a risk if a function executed during COPY
> tried to change one of the above-mentioned parameters.  Since COPY OUT
> doesn't fire triggers, I think user-defined datatype output functions
> would be the only possible candidates for that.

Understood

> * LISTEN/NOTIFY isn't a risk because the backend only sends NOTIFY at
> transaction end, period.

OK, just seen the comment section above the case statement.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com