Re: [HACKERS] Odd behavior with PG_TRY

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] Odd behavior with PG_TRY
Дата
Msg-id CAA4eK1Kw6GcGd8Yz1yg4sb4_60ayVAMWuhsRCaXPy+FqfDKwZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Odd behavior with PG_TRY  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] Odd behavior with PG_TRY  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables
Следующее
От: Stas Kelvich
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions