On 12/22/2016 06:55 AM, Tom Lane wrote:
> Joe Conway writes:
>> On 12/21/2016 09:20 PM, Tom Lane wrote:
>>> 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:
Joe Conway writes:
> On 12/21/2016 09:20 PM, Tom Lane wrote:
>> 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:
Oh! I misread the patch --- something about a
On 12/21/2016 09:20 PM, Tom Lane wrote:
> Joe Conway 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 poi
Joe Conway 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?
> You think it
On 12/21/2016 04:22 PM, Tom Lane wrote:
> Joe Conway 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-le
Joe Conway 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, no
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("E
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.
On 12/21/2016 09:27 AM, Tom Lane wrote:
> Joe Conway writes:
>> On 12/21/2016 08:49 AM, Tom Lane 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.
>>>
>>> postgres_fdw has the same disease.
Joe Conway writes:
> On 12/21/2016 08:49 AM, Tom Lane 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.
>>
>> postgres_fdw has the same disease. It wouldn't have the notion of a named
>> conne
On 12/21/2016 08:49 AM, Tom Lane wrote:
> We have a report in pgsql-general of a dblink query failing with
> ERROR: unknown error
> This is, to say the least, unhelpful. And it violates our error
> message style guidelines.
>
> Where that is coming from is a situation where we've failed to
"David G. Johnston" writes:
> On Wed, Dec 21, 2016 at 9:49 AM, Tom Lane wrote:
>> A possible objection is that if we really are on the hairy edge of OOM,
>> trying to construct such error strings might push us over the edge
> What am I missing here? Constructing said string occurs on the local
I wrote:
> We have a report in pgsql-general of a dblink query failing with
> ERROR: unknown error
Er, fingers faster than brain this morning. Actually that report is in
pgsql-bugs, specifically bug #14471:
https://www.postgresql.org/message-id/20161221094443.25614.47807%40wrigleys.postgres
On Wed, Dec 21, 2016 at 9:49 AM, Tom Lane wrote:
> A possible objection is that if we really are on the hairy edge of OOM,
> trying to construct such error strings might push us over the edge
What am I missing here? Constructing said string occurs on the local end
of the connection but the mem
We have a report in pgsql-general of a dblink query failing with
ERROR: unknown error
This is, to say the least, unhelpful. And it violates our error
message style guidelines.
Where that is coming from is a situation where we've failed to extract
any primary message from a remote error.
15 matches
Mail list logo