Skip to content
Snippets Groups Projects
  • Tom Lane's avatar
    9422b61d
    Fix freshly-introduced PL/Python portability bug. · 9422b61d
    Tom Lane authored
    It turns out that those PyErr_Clear() calls I removed from plpy_elog.c
    in 7e3bb080 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.
    9422b61d
    History
    Fix freshly-introduced PL/Python portability bug.
    Tom Lane authored
    It turns out that those PyErr_Clear() calls I removed from plpy_elog.c
    in 7e3bb080 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.