Re: [HACKERS] Odd behavior with PG_TRY

On 1/3/17 9:20 PM, Amit Kapila wrote:
> 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.

I can run some other experiments if you have any to suggest.

I do think it's interesting that the data appeared to be completely fine 
until I actually ran whatever the first assembly instruction of the for 
loop is, so presumably it was fine after the sigsetjmp() call (which I'm 
assuming is what causes all the fuss to begin with...) From my 
understanding of what volatile does, I can understand why it might be 
necessary for something in the CATCH block to need it, but not in the TRY.

Two other things of note that might possibly make a difference here:

- This is happening inside a function used as a DestReceiver receiver
- The original call is a plpython function, calling a plpython function, 
calling a plpython function (specifically, nested_call_one() in the 
plpython regression test).

That does mean that the call stack looks something like this:

plpython
SPI_execute_callback
(my customer DestReceiverer Setup function (PLy_CSSetup) is called 
somewhere in here, which is what populates myState)
plpython
SPI_execute_callback
(PLy_CSSetup gets called again)
plpython (this just returns a value)
After that plpython call, the executor is going to call PLy_CSreceive, 
which is the function with this problematic code. So by the time this 
error happens, there are two nested levels of plpython+SPI going on. I 
originally thought the re-entrant calls were causing the problem, but 
after monitoring what PLy_CSSetup was doing and what PLy_CSreceive was 
getting that's not the case, or at least not the only reason for this.
-- 
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)