On 12/21/2016 10:08 AM, Tom Lane wrote:
> I wrote:
>>>> I propose that we should change that string to "could not obtain message
>>>> string for error on connection "foo"", or something along that line.
>
> BTW, looking closer, I notice that the dblink case already has
>
> errcontext("Error occurred on dblink connection named \"%s\": %s.",
> dblink_context_conname, dblink_context_msg)));
>
> so we probably don't need the connection name in the primary error
> message. Now I think "could not obtain message string for remote error"
> would be a sufficient message.
>
> In the postgres_fdw case, I'd be inclined to use the same replacement
> primary message. Maybe we should think about adding the server name
> to the errcontext there, but that seems like an independent improvement.
Committed that way.
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.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
