Re: [HACKERS] Odd behavior with PG_TRY - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [HACKERS] Odd behavior with PG_TRY
Date
Msg-id 10cb1803-dbb4-4428-94d0-395d2c607a54@BlueTreble.com
Whole thread Raw
In response to Re: [HACKERS] Odd behavior with PG_TRY  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Odd behavior with PG_TRY
List pgsql-hackers
On 1/2/17 1:31 AM, Amit Kapila wrote:
> On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> In the attached patch (snippet below), I'm seeing something strange with
>> args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things
>> in lldb just fine:
>>
>> (lldb) call args->in.r.atts[0].func
>> (PLyDatumToObFunc) $49 = 0x000000010fc4dc70
>> (plpython3.so`PLyString_FromDatum at plpy_typeio.c:621)
>> (lldb) call &args->in.r.atts[0]
>> (PLyDatumToOb *) $50 = 0x00007fd2b302f6d0
>> (lldb) call args->in.r.atts[0]
>> (PLyDatumToOb) $51 = {
>>   func = 0x000000010fc4dc70 (plpython3.so`PLyString_FromDatum at
>> plpy_typeio.c:621)
>>   typfunc = {
>>     fn_addr = 0x000000010f478b50 (postgres`textout at varlena.c:521)
>>     fn_oid = 47
>> ...
>>
>> But I'm getting a EXC_BAD_ACCESS (code=1, address=0xb302f6d0) on the last if
>> in the snippet below. Looking at the variables again, I see:
>>
>> (lldb) call args->in.r.atts[i].func
>> error: Couldn't apply expression side effects : Couldn't dematerialize a
>> result variable: couldn't read its memory
>> (lldb) call args->in.r.atts[i]
>> error: Couldn't apply expression side effects : Couldn't dematerialize a
>> result variable: couldn't read its memory
>>
>
> Looks strange, what is the value of 'i'?  Did you get the same result
> if you try to print args->in.r.atts[0] inside PG_TRY?

i is 0, makes no difference:

(lldb) call i
(int) $56 = 0
(lldb) call args->in.r.atts[0]
error: Couldn't apply expression side effects : Couldn't dematerialize a 
result variable: couldn't read its memory
(lldb)
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Fixing pgbench's logging of transaction timestamps