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

From Tom Lane
Subject Re: [HACKERS] Odd behavior with PG_TRY
Date
Msg-id 31436.1483415248@sss.pgh.pa.us
Whole thread Raw
In response to [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
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> In the attached patch (snippet below), I'm seeing something strange with 
> args->in.r.atts[].

Did you try comparing the apparent values of "args" before and after
entering PG_TRY?

> I saw the comment on PG_TRY about marking things as volatile, but my 
> understanding from the comment is I shouldn't even need to do that, 
> since these variables aren't being modified.

Not sure, but if you do need to mark them volatile to prevent
misoptimization in the PG_TRY, this is not how to do it:

> volatile TupleDesc    desc = slot->tts_tupleDescriptor;
> volatile CallbackState *myState = (CallbackState *) self;
> volatile PLyTypeInfo *args = myState->args;

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Odd behavior with PG_TRY
Next
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)