Marina Polyakova writes:
> On 14-02-2018 17:54, Tom Lane wrote:
>> 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
On 14-02-2018 17:54, Tom Lane wrote:
Marina Polyakova 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?
T
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 =
Marina Polyakova 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, inst
On 14-02-2018 3:43, Peter Eisentraut wrote:
On 2/13/18 05:40, Marina Polyakova wrote:
Binary search has shown that this failure begins with commit
8561e4840c81f7e345be2df170839846814fa004 (Transaction control in PL
procedures.). On the previous commit
(b9ff79b8f17697f3df492017d454caa9920a7183) t
On 2/13/18 05:40, Marina Polyakova wrote:
> Binary search has shown that this failure begins with commit
> 8561e4840c81f7e345be2df170839846814fa004 (Transaction control in PL
> procedures.). On the previous commit
> (b9ff79b8f17697f3df492017d454caa9920a7183) there's no
> plpython_transaction te
