Re: Odd behavior with PG_TRY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior with PG_TRY
Date: 2017-01-03 03:47:28
Message-ID: 31436.1483415248@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2017-01-03 04:13:38 Re: Patch: Write Amplification Reduction Method (WARM)
Previous Message Amit Kapila 2017-01-03 03:15:30 Re: Odd behavior with PG_TRY