From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Marina Polyakova <m.polyakova@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org
Subject: Re: master plpython check fails on Solaris 10
Date: Wed, 14 Feb 2018 10:51:45 -0500
Message-ID: <26306.1518623505@sss.pgh.pa.us> (raw)
In-Reply-To: <17568.1518620054@sss.pgh.pa.us>
References: <156b989dbc6fe7c4d3223cf51da61195@postgrespro.ru>
<4a5588c7-9bcc-d5f5-b952-6b260467fc71@2ndquadrant.com>
<2982e7d95f11eea5599f8141efbf4b2d@postgrespro.ru>
<17568.1518620054@sss.pgh.pa.us>
I wrote:
> so how come this test case doesn't crash for everybody?
I traced through this, and what I see is that the error information
constructed at the time of the inner ereport includes
0x1f98528 "invalid transaction termination", detail = 0x0, detail_log =
0x0, hint = 0x0, context =
0x1f98598 "PL/Python anonymous code block\nSQL statement \"DO LANGUAGE plpythonu $x$ plpy.commit() $x$\"\nPL/Python function \"(null)\"", message_id =
0xa0fc50 "invalid transaction termination", schema_name = 0x0,
So, in fact, we *are* passing a null pointer to sprintf here.
Apparently, none of the machines in the buildfarm crash on that,
or at least none of the ones building plpython do, which is
pretty troubling from a test coverage standpoint. I suggest that
it might be a good idea to insert an "Assert(strvalue != NULL)"
in src/port/snprintf.c, approx. line 748, so that at least the
machines using that fallback implementation are guaranteed to
whine about this type of mistake.
The reason we don't see this obviously-bogus output in the test
results is that when control exits the outer Python function,
the inner error result is thrown away during
PLy_abort_open_subtransactions, and then we generate an all-new error
report with "PLy_elog(ERROR, NULL)". That contains only Python's
own traceback plus the output from a (duplicate) call of
plpython_error_callback, which now gets the right answer because
PLy_execution_contexts is now pointing at the outer function's
context.
So I'm still thinking I can construct a test case in which plpython
outputs a clearly-wrong context stack, but it will have to involve
elog(NOTICE) rather than ERROR. Will work on that.
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, peter.eisentraut@2ndquadrant.com, m.polyakova@postgrespro.ru
Subject: Re: master plpython check fails on Solaris 10
In-Reply-To: <26306.1518623505@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