Re: Odd behavior with PG_TRY

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior with PG_TRY
Date: 2017-01-05 10:10:18
Message-ID: CAA4eK1Kw6GcGd8Yz1yg4sb4_60ayVAMWuhsRCaXPy+FqfDKwZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 5, 2017 at 4:18 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stas Kelvich 2017-01-05 10:21:10 Re: logical decoding of two-phase transactions
Previous Message Pavel Stehule 2017-01-05 10:04:09 Re: proposal: session server side variables