Обсуждение: [HACKERS] Consistently catch errors from Python _New() functions

While reviewing some unrelated code, I noticed that we are handling
error conditions from Python API functions such as PyList_New() and
PyDict_New() in pretty random ways or not at all.  Here is a patch to
fix that.

Arguably, this is a bug fix, but I'm not sure whether it's worth
meddling with this in the back branches.  Maybe only the places where
the errors are not caught at all should be fixed there.  Comments welcome.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> While reviewing some unrelated code, I noticed that we are handling
> error conditions from Python API functions such as PyList_New() and
> PyDict_New() in pretty random ways or not at all.  Here is a patch to
> fix that.

This needs some adjustment in the wake of 687f096ea.

I'm confused by the places that change PLy_elog calls to pass NULL:

-        PLy_elog(ERROR, "could not create globals");
+        PLy_elog(ERROR, NULL);

How is that an improvement?  Otherwise it looks reasonable.
        regards, tom lane

On 11/17/17 12:16, Tom Lane wrote:
> I'm confused by the places that change PLy_elog calls to pass NULL:
> 
> -        PLy_elog(ERROR, "could not create globals");
> +        PLy_elog(ERROR, NULL);
> 
> How is that an improvement?  Otherwise it looks reasonable.

If we pass NULL, then the current Python exception becomes the primary
error, so you'd end up with an "out of memory" error of some kind with a
stack trace, which seems useful.

The previous coding style invented a bespoke error message for each of
these rare out of memory scenarios, which seems wasteful.  We don't
create "out of memory while creating some internal list you've never
heard of" errors elsewhere either.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 11/17/17 12:16, Tom Lane wrote:
>> I'm confused by the places that change PLy_elog calls to pass NULL:
>> 
>> -        PLy_elog(ERROR, "could not create globals");
>> +        PLy_elog(ERROR, NULL);
>> 
>> How is that an improvement?  Otherwise it looks reasonable.

> If we pass NULL, then the current Python exception becomes the primary
> error, so you'd end up with an "out of memory" error of some kind with a
> stack trace, which seems useful.

Oh, I see.  Objection withdrawn.
        regards, tom lane

On 11/18/17 12:05, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 11/17/17 12:16, Tom Lane wrote:
>>> I'm confused by the places that change PLy_elog calls to pass NULL:
>>>
>>> -        PLy_elog(ERROR, "could not create globals");
>>> +        PLy_elog(ERROR, NULL);
>>>
>>> How is that an improvement?  Otherwise it looks reasonable.
> 
>> If we pass NULL, then the current Python exception becomes the primary
>> error, so you'd end up with an "out of memory" error of some kind with a
>> stack trace, which seems useful.
> 
> Oh, I see.  Objection withdrawn.

Committed, thanks.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services