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

On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> 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

Committed, but... why do we EVER need to call CheckConnection() at the
bottom of ProcessResult(), after exiting that function's main loop? I
don't see any way to get out of that loop without first calling
AcceptResult on every PGresult we've seen, and that function already
calls CheckConnection() if any failure is observed.

As a side note, the documentation for PQexec() is misleading about
what will happen if COPY is present in a multi-command string. It
says: "Note however that the returned PGresult structure describes
only the result of the last command executed from the string. Should
one of the commands fail, processing of the string stops with it and
the returned PGresult describes the error condition. It does not
explain that it also stops if it hits a COPY. I had to read the
source code for libpq to understand why this psql logic was coded the
way it is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company