From 1d2f9de38d18152f83cf570581cebac0733ff504 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 11 Apr 2016 18:17:02 -0400 Subject: [PATCH] Fix freshly-introduced PL/Python portability bug. It turns out that those PyErr_Clear() calls I removed from plpy_elog.c in 7e3bb080387f4143 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. --- src/pl/plpython/plpy_elog.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/pl/plpython/plpy_elog.c b/src/pl/plpython/plpy_elog.c index 7d3d0d4981..7495e7d51d 100644 --- a/src/pl/plpython/plpy_elog.c +++ b/src/pl/plpython/plpy_elog.c @@ -255,6 +255,12 @@ PLy_traceback(PyObject *e, PyObject *v, PyObject *tb, 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"); if (lineno == NULL) elog(ERROR, "could not get line number from Python traceback"); -- 2.40.0