Re: BUG #11712: Empty string as error message from libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: marko(at)joh(dot)to
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #11712: Empty string as error message from libpq
Date: 2014-10-22 22:16:01
Message-ID: 31203.1414016161@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

marko(at)joh(dot)to writes:
> 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.

Hmm. I wonder why we're not getting ECONNRESET, since surely the TCP
stack knows the other end is dead? Anyway, it looks to me like the
best fix is just to set an error message, ie copy this bit

printfPQExpBuffer(&conn->errorMessage,
libpq_gettext(
"server closed the connection unexpectedly\n"
"\tThis probably means the server terminated abnormally\n"
"\tbefore or while processing the request.\n"));

right before definitelyFailed:. For the goto's leading to that label,
it's reasonable to expect that lower-level code set the errorMessage,
but this will not have happened when pqsecure_read returns zero, since
the whole point is that it doesn't know there's anything wrong.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message ua.san.alex 2014-10-22 23:57:02 BUG #11768: "jsonb ?" - not support int type operator
Previous Message keyurgovande 2014-10-22 21:22:10 BUG #11767: ODBC driver bug when fetching constant string columns