mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-04 15:57:19 +02:00
Fix freshly-introduced PL/Python portability bug.
It turns out that those PyErr_Clear() calls I removed from plpy_elog.c
in 7e3bb08038
et al were not quite as random as they appeared: they
mask a Python 2.3.x bug. (Specifically, it turns out that PyType_Ready()
can fail if the error indicator is set on entry, and PLy_traceback's fetch
of frame.f_code may be the first operation in a session that requires the
"frame" type to be readied. Ick.) Put back the clear call, but in a more
centralized place closer to what it's protecting, and this time with a
comment warning what it's really for.
Per buildfarm member prairiedog. Although prairiedog was only failing
on HEAD, it seems clearly possible for this to occur in older branches
as well, so back-patch to 9.2 the same as the previous patch.
This commit is contained in:
parent
ec91ee8f00
commit
8207c6baf8
@ -226,6 +226,12 @@ PLy_traceback(PyObject *e, PyObject *v, PyObject *tb,
|
|||||||
|
|
||||||
PG_TRY();
|
PG_TRY();
|
||||||
{
|
{
|
||||||
|
/*
|
||||||
|
* Ancient versions of Python (circa 2.3) contain a bug whereby
|
||||||
|
* the fetches below can fail if the error indicator is set.
|
||||||
|
*/
|
||||||
|
PyErr_Clear();
|
||||||
|
|
||||||
lineno = PyObject_GetAttrString(tb, "tb_lineno");
|
lineno = PyObject_GetAttrString(tb, "tb_lineno");
|
||||||
if (lineno == NULL)
|
if (lineno == NULL)
|
||||||
elog(ERROR, "could not get line number from Python traceback");
|
elog(ERROR, "could not get line number from Python traceback");
|
||||||
|
Loading…
Reference in New Issue
Block a user