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 CAA4eK1Kw6GcGd8Yz1yg4sb4_60ayVAMWuhsRCaXPy+FqfDKwZQ@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  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Jan 5, 2017 at 4:18 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 1/3/17 9:20 PM, Amit Kapila wrote:
>>
>>
>> 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.
>

Memory contexts used in catch block also doesn't seem to be marked as
volatile, you might want to try by marking them as volatile.  Also, it
might worth trying it on some other system to see if you are by any
chance hitting the problem similar to what Tom has faced.


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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: session server side variables
Next
From: Stas Kelvich
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions