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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Getting rid of "unknown error" in dblink and postgres_fdw
Date: 2016-12-22 00:22:09
Message-ID: 19852.1482366129@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2016-12-22 00:55:47 Re: SET NOT NULL [NOT VALID / CONCURRENTLY]?
Previous Message Joe Conway 2016-12-22 00:12:34 Re: Getting rid of "unknown error" in dblink and postgres_fdw