From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marina Polyakova <m.polyakova@postgrespro.ru>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: master plpython check fails on Solaris 10
Date: Wed, 14 Feb 2018 09:54:14 -0500
Message-ID: <17568.1518620054@sss.pgh.pa.us> (raw)
In-Reply-To: <2982e7d95f11eea5599f8141efbf4b2d@postgrespro.ru>
References: <156b989dbc6fe7c4d3223cf51da61195@postgrespro.ru>
<4a5588c7-9bcc-d5f5-b952-6b260467fc71@2ndquadrant.com>
<2982e7d95f11eea5599f8141efbf4b2d@postgrespro.ru>
Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> On 14-02-2018 3:43, Peter Eisentraut wrote:
>> OK, can you get some kind of stack trace or other debugging
>> information?
> I got this backtrace from gdb:
Hmm, so the only question in my mind is how did this ever work for anyone?
The basic problem here is that, instead of using the
ErrorContextCallback.arg field provided for the purpose,
plpython_error_callback is using PLy_current_execution_context()
to try to identify the context it's supposed to report on.
In the example, that points to the context associated with the
inner DO block, not with the outer procedure. That context
looks like it should reliably have curr_proc->proname == NULL,
so how come this test case doesn't crash for everybody?
In any case the expected output for the transaction_test4
case is obviously wrong. Rather than reporting the transaction_test4
function and then the inner DO block, it's reporting 2 levels
of transaction_test4. That seems to trace directly to both levels
of error context callback looking at the same execution context.
I think we need to fix the error callback code so that it
uses the "arg" field to find the relevant procedure, and that
that's a back-patchable fix, because nested plpython functions
would show this up as wrong in any case. That would also let us
undo the not-terribly-safe practice of having code between the
PLy_push_execution_context call and the PG_TRY that is supposed
to ensure the context gets popped again.
While I'm bitching ... I wonder how long it's been since the
comment for PLy_procedure_name() had anything to do with its
actual behavior.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, m.polyakova@postgrespro.ru, peter.eisentraut@2ndquadrant.com
Subject: Re: master plpython check fails on Solaris 10
In-Reply-To: <17568.1518620054@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox