Horton

Re: Getting rid of "unknown error" in dblink and postgres_fdw

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgresql.org
Date: 2016-12-22T00:22:09Z
Lists: pgsql-hackers 
Joe Conway <mail@joeconway.com> writes:
> I did notice that postgres_fdw has the following stanza that I don't see
> in dblink:

> 8<------------------
> /*
>  * If we don't get a message from the PGresult, try the PGconn.  This
>  * is needed because for connection-level failures, PQexec may just
>  * return NULL, not a PGresult at all.
>  */
> if (message_primary == NULL)
> 	message_primary = PQerrorMessage(conn);
> 8<------------------

> I wonder if the original issue on pgsql-bugs was a connection-level
> failure rather than OOM? Seems like dblink ought to do the same.

Oooh ... I had thought that code was in both, which was why I was having
a hard time explaining the OP's failure.  But I see you're right,
which provides a very straightforward explanation for the report.
I believe that if libpq is unable to malloc a PGresult, it will return
NULL but put an "out of memory" message into the PGconn's error buffer.
I had supposed that we'd capture and report the latter, but as the
dblink code stands, it won't.

In short, yes, please copy that bit into dblink.

			regards, tom lane

Commits

  1. Make dblink try harder to form useful error messages

  2. Improve dblink error message when remote does not provide it