Thread: [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
Attachment
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