Consistently catch errors from Python _New() functions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37653psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 09:59 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37653_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37653_1 && git checkout t37653_1Patchset v1 (message #1) is on t37653_1
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
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