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

From Amit Kapila
Subject Re: [HACKERS] Odd behavior with PG_TRY
Date
Msg-id CAA4eK1JD1tAscqEyp3K1VX=APqHf+Y3=ittu2hxErWUnkke1LA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Odd behavior with PG_TRY  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] Odd behavior with PG_TRY  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 1/2/17 9:47 PM, Tom Lane wrote:
>> Correct coding would be
>>
>>     volatile TupleDesc  desc = slot->tts_tupleDescriptor;
>>     CallbackState * volatile myState = (CallbackState *) self;
>>     PLyTypeInfo * volatile args = myState->args;
>>
>> because what needs to be marked volatile is the pointer variable,
>> not what it points at.  I'm a bit surprised you're not getting
>> "cast away volatile" warnings from the code as you have it.
>
>
> Unfortunately, that didn't make a difference. Amit's suggestion of isolating
> the single statement in a PG_TRY() didn't work either, but assigning
> args->in.r.atts[i] to a pointer did.
>

Good to know that it worked, but what is the theory?  From your
experiment, it appears that in some cases accessing local pointer
variables is okay and in other cases, it is not okay.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Logical decoding - filtering tables
Next
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] pg_hba_file_settings view patch