Avoid possible longjmp-induced logic error in PLy_trigger_build_args.
The "pltargs" variable wasn't marked volatile, which makes it unsafe to change its value within the PG_TRY block. It looks like the worst outcome would be to fail to release a refcount on Py_None during an (improbable) error exit, which would likely go unnoticed in the field. Still, it's a bug. A one-liner fix could be to mark pltargs volatile, but on the whole it seems cleaner to arrange things so that we don't change its value within PG_TRY. Per report from Xing Guo. This has been there for quite awhile, so back-patch to all supported branches. Discussion: https://postgr.es/m/CACpMh+DLrk=fDv07MNpBT4J413fDAm+gmMXgi8cjPONE+jvzuw@mail.gmail.com
This commit is contained in:
parent
91cbb4b492
commit
5eac8cef24
|
@ -689,7 +689,7 @@ PLy_trigger_build_args(FunctionCallInfo fcinfo, PLyProcedure *proc, HeapTuple *r
|
|||
*pltrelid,
|
||||
*plttablename,
|
||||
*plttableschema,
|
||||
*pltargs = NULL,
|
||||
*pltargs,
|
||||
*pytnew,
|
||||
*pytold,
|
||||
*pltdata;
|
||||
|
@ -713,6 +713,11 @@ PLy_trigger_build_args(FunctionCallInfo fcinfo, PLyProcedure *proc, HeapTuple *r
|
|||
return NULL;
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
Py_INCREF(Py_None);
|
||||
pltargs = Py_None;
|
||||
}
|
||||
|
||||
PG_TRY();
|
||||
{
|
||||
|
@ -856,7 +861,7 @@ PLy_trigger_build_args(FunctionCallInfo fcinfo, PLyProcedure *proc, HeapTuple *r
|
|||
PyObject *pltarg;
|
||||
|
||||
/* pltargs should have been allocated before the PG_TRY block. */
|
||||
Assert(pltargs);
|
||||
Assert(pltargs && pltargs != Py_None);
|
||||
|
||||
for (i = 0; i < tdata->tg_trigger->tgnargs; i++)
|
||||
{
|
||||
|
@ -870,8 +875,7 @@ PLy_trigger_build_args(FunctionCallInfo fcinfo, PLyProcedure *proc, HeapTuple *r
|
|||
}
|
||||
else
|
||||
{
|
||||
Py_INCREF(Py_None);
|
||||
pltargs = Py_None;
|
||||
Assert(pltargs == Py_None);
|
||||
}
|
||||
PyDict_SetItemString(pltdata, "args", pltargs);
|
||||
Py_DECREF(pltargs);
|
||||
|
|
Loading…
Reference in New Issue