Re: BUG #11712: Empty string as error message from libpq
От | Tom Lane |
---|---|
Тема | Re: BUG #11712: Empty string as error message from libpq |
Дата | |
Msg-id | 31203.1414016161@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #11712: Empty string as error message from libpq (marko@joh.to) |
Список | pgsql-bugs |
marko@joh.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
В списке pgsql-bugs по дате отправления: