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

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

On 12/21/2016 09:20 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> On 12/21/2016 04:22 PM, Tom Lane wrote:
>>> In short, yes, please copy that bit into dblink.
>
>> The attached should do the trick I think.
>
> I see that you need to pass the PGconn into dblink_res_error() now, but
> what's the point of the new "bool fail" parameter?

That part isn't new -- we added it sometime prior to 9.2:

8<--------------
if (fail)
level = ERROR;
else
level = NOTICE;
8<--------------

It allows dblink to throw a NOTICE on remote errors rather than an
actual ERROR, e.g. for an autonomous transaction.

From the docs (9.2 in this case)
8<--------------
fail_on_error

If true (the default when omitted) then an error thrown on the
remote side of the connection causes an error to also be thrown locally.
If false, the remote error is locally reported as a NOTICE, and the
function returns no rows.
8<--------------

>> You think it is reasonable to backpatch this part too?
>
> Yes, definitely.

Ok, will do.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2016-12-22 06:12:58 [bug fix] Trivial ecpg bug which can cause memory overrun
Previous Message Michael Paquier 2016-12-22 05:43:38 Re: Logical decoding on standby