BUG #11712: Empty string as error message from libpq

The following bug has been logged on the website:

Bug reference:      11712
Logged by:          Marko Tiikkaja
Email address:      marko@joh.to
PostgreSQL version: 9.4beta2
Operating system:   OS X
Description:

Hi,

This has been annoying me for a while, but I never got around to reporting
the bug.  Reproduced on 9.1 and just tried against HEAD.  Here it is in all
its glory.

Consider a program similar to the LISTEN/NOTIFY example here:
http://www.postgresql.org/docs/9.3/static/libpq-example.html#LIBPQ-EXAMPLE-2,
but with an added error handling around PQconsumeInput():

        if (PQconsumeInput(conn) != 1) {
            fprintf(stderr,
                    "PQconsumeInput() failed: %s\n",
                    PQerrorMessage(conn));
            PQfinish(conn);
            return;
        }

Now when this program is running without SSL, and the server closes the
network connection, what happens is this:

  PQconsumeInput() failed:

i.e. the error string is empty.  This happens when recv() returns 0 on EOF.
pqsecure_write() says the following: "On failure, this function is
responsible for putting a suitable message into conn->errorMessage", but
apparently it doesn't consider recv() returning 0 a "failure", which I guess
is fine.  However, pqReadData() goes through all the fancy logic of
determining that what happened was really an EOF, and then says the
following:

    /*
     * OK, we are getting a zero read even though select() says ready. This
     * means the connection has been closed.  Cope.  Note that errorMessage
     * has been set already.
     */

But I don't see who's supposed to have been set errorMessage in that case.
I think that might be true for SSL code paths, but it's certainly not true
for the non-SSL ones.