Kevin Grittner writes:
> On Fri, Jan 6, 2017 at 5:43 AM, Michael Paquier
> wrote:
>> If a variable is modified within PG_TRY and then referenced in
>> PG_CATCH it needs to be marked as volatile to be strictly in
>> conformance with POSIX. This also ensures that any compiler does not
>> do any stu
On Fri, Jan 6, 2017 at 5:43 AM, Michael Paquier
wrote:
> If a variable is modified within PG_TRY and then referenced in
> PG_CATCH it needs to be marked as volatile to be strictly in
> conformance with POSIX. This also ensures that any compiler does not
> do any stupid optimizations with those va
On Thu, Jan 5, 2017 at 7:10 PM, Amit Kapila wrote:
> 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 sim
On Thu, Jan 5, 2017 at 4:18 AM, Jim Nasby 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 ca
Jim Nasby writes:
> 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.
On 1/3/17 9:20 PM, Amit Kapila wrote:
On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby 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
On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby 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;
>>
On 1/2/17 9:47 PM, Tom Lane wrote:
Jim Nasby 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?
Yeah, see below. FWIW, when I did that just now I stepped th
Jim Nasby 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 th
On Mon, Jan 2, 2017 at 10:43 PM, Jim Nasby wrote:
> On 1/2/17 1:31 AM, Amit Kapila wrote:
>>
>> On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby
>> wrote:
>>
>> Looks strange, what is the value of 'i'? Did you get the same result
>> if you try to print args->in.r.atts[0] inside PG_TRY?
>
>
> i is 0, m
On 1/2/17 1:31 AM, Amit Kapila wrote:
On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby wrote:
In the attached patch (snippet below), I'm seeing something strange with
args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things
in lldb just fine:
(lldb) call args->in.r.atts[0].func
(P
On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby wrote:
> In the attached patch (snippet below), I'm seeing something strange with
> args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things
> in lldb just fine:
>
> (lldb) call args->in.r.atts[0].func
> (PLyDatumToObFunc) $49 = 0x0
In the attached patch (snippet below), I'm seeing something strange with
args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect
things in lldb just fine:
(lldb) call args->in.r.atts[0].func
(PLyDatumToObFunc) $49 = 0x00010fc4dc70
(plpython3.so`PLyString_FromDatum at plpy_type
13 matches
Mail list logo
