Re: psql COPY vs. ON_ERROR_ROLLBACK, multi-command strings

On Wed, Jan 25, 2012 at 06:25:46PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of s??b ene 14 12:40:02 -0300 2012:
> > It has bothered me that psql's \copy ignores the ON_ERROR_ROLLBACK setting.
> > Only SendQuery() takes note of ON_ERROR_ROLLBACK, and \copy, like all
> > backslash commands, does not route through SendQuery(). Looking into this
> > turned up several other weaknesses in psql's handling of COPY.
>
> Interesting.
>
> Committed, thanks.

Thanks. While testing a crashing function, I noticed that my above patch
added some noise to psql output when the server crashes:

[local] test=# select crashme();
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
unexpected transaction status (4)
Time: 6.681 ms
!> \q

Status 4 is PQTRANS_UNKNOWN, which is expected when the connection is not
CONNECTION_OK. The double message arrives because ProcessResult() now calls
CheckConnection() at least twice, for the benefit of COPY. (Incidentally, the
reconnect fails because the server has not yet finished recovering; that part
is nothing new.)

The attached small patch has SendQuery() keep quiet about PQTRANS_UNKNOWN when
the connection is down. It makes ProcessResult() skip the second
CheckConnection() when the command string had no COPY results. This restores
the pre-08146775acd8bfe0fcc509c71857abb928697171 psql output:

[local] test=# select crashme();
The connection to the server was lost. Attempting reset: Failed.
Time: 4.798 ms
!> \q

Thanks,
nm