Re: [HACKERS] Odd behavior with PG_TRY

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] Odd behavior with PG_TRY
Дата
Msg-id 3875fccc-178f-51b5-87a2-dddede565aa7@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Odd behavior with PG_TRY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Odd behavior with PG_TRY  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 1/2/17 9:47 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> 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 through at the 
instruction level, and things went belly up when I stepped into the 
first instruction of the for (first instruction after PG_TRY was done).

>> I saw the comment on PG_TRY about marking things as volatile, but my
>> understanding from the comment is I shouldn't even need to do that,
>> since these variables aren't being modified.
>
> Not sure, but if you do need to mark them volatile to prevent
> misoptimization in the PG_TRY, this is not how to do it:
>
>> volatile TupleDesc    desc = slot->tts_tupleDescriptor;
>> volatile CallbackState *myState = (CallbackState *) self;
>> volatile PLyTypeInfo *args = myState->args;
>
> 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. The volatile didn't make 
a difference in this case, which if the PG_TRY() comments are to be 
believed is what I'd expect. Though, it was also OK with value not being 
volatile, which AFAIK isn't safe, so...
for (i = 0; i < desc->natts; i++){    PyObject   *value = NULL;    PLyDatumToOb * volatile atts = &args->in.r.atts[i];

...
    if (slot->tts_isnull[i] || atts->func == NULL)    {        Py_INCREF(Py_None);        value = Py_None;    }    else
  {        PG_TRY();        {            value = (atts->func) (atts, slot->tts_values[i]);        }        PG_CATCH();
     {            Py_XDECREF(value);            MemoryContextSwitchTo(oldcontext);
PLy_switch_execution_context(old_exec_ctx);           PG_RE_THROW();        }        PG_END_TRY();    }
 

lldb output from inspecting variables:

(lldb) call args
(volatile PLyTypeInfo *) $60 = 0x00007fff5912fbe8
(lldb) call @args
error: expected expression
(lldb) call *args
(PLyTypeInfo) $61 = {  in = {    d = {      func = 0x00007fca218f8ed0      typfunc = {        fn_addr =
0x00007fff00000001       fn_oid = 114610686        fn_nargs = 1        fn_strict = '\0'        fn_retset = '\0'
fn_stats= '0'        fn_extra = 0x00007fca2206d060        fn_mcxt = 0x00007fca22800960        fn_expr =
0x00007fff5912fbe8     }      typtransform = {        fn_addr = 0x00007fca218f8e38        fn_oid = 570849696
fn_nargs= 32714        fn_strict = '\0'        fn_retset = '\0'        fn_stats = '8'        fn_extra =
0x00007fca22066f60       fn_mcxt = 0x00007fff5912fc90        fn_expr = 0x0000000106d7df6f      }      typoid =
570830824     typmod = 32714      typioparam = 570830864      typbyval = '\0'      typlen = 0      typalign = 'h'
elm= 0x0000000000000000    }    r = {      atts = 0x00007fca218f8ed0      natts = 1    }  }  out = {    d = {      func
=0x00007fca22066f60      typfunc = {        fn_addr = 0x00007fca00000000        fn_oid = 570846544        fn_nargs =
32714       fn_strict = '\0'        fn_retset = '\0'        fn_stats = '`'        fn_extra = 0x00007fff5912fce0
fn_mcxt= 0x0000000106d4d437        fn_expr = 0x00007fca2206ce30      }      typtransform = {        fn_addr =
0x00007fca22062f90       fn_oid = 0        fn_nargs = 0        fn_strict = '\0'        fn_retset = '\0'        fn_stats
='\0'        fn_extra = 0xffffffdc22066c20        fn_mcxt = 0x0000000000000000        fn_expr = 0x00007fca22066f60
}     typoid = 3756919206      typmod = -754934605      typioparam = 1494416704      typbyval = '\xff'      typlen = 0
   typalign = '^'      elm = 0x00007fff5912fd10    }    r = {      atts = 0x00007fca22066f60      natts = 0    }  }
is_rowtype= 0  typ_relid = 0  typrel_xmin = 570847072  typrel_tid = {    ip_blkid = (bi_hi = 32714, bi_lo = 0)
ip_posid= 36408  }  mcxt = 0x000000012206c6f0
 
}
(lldb) gu
(lldb) call args
(volatile PLyTypeInfo *) $62 = 0x00007fff5912fbe8
(lldb) call *args
(PLyTypeInfo) $63 = {  in = {    d = {      func = 0x00000000218f8ed0      typfunc = {        fn_addr =
0x00007fff5912ff08       fn_oid = 1494417744        fn_nargs = 32767        fn_strict = '\0'        fn_retset = '\0'
   fn_stats = '0'        fn_extra = 0x00007fca2206d060        fn_mcxt = 0x00007fca22800960        fn_expr =
0x00007fff5912fbe8     }      typtransform = {        fn_addr = 0x00007fca218f8e38        fn_oid = 570849696
fn_nargs= 32714        fn_strict = '\0'        fn_retset = '\0'        fn_stats = '8'        fn_extra =
0x00007fca22066f60       fn_mcxt = 0x0000000000000000        fn_expr = 0x00007fff5912fce0      }      typoid =
1494416304     typmod = 32767      typioparam = 114900880      typbyval = '\x01'      typlen = 0      typalign = '\xa6'
    elm = 0x000000010735c8a0    }    r = {      atts = 0x00000000218f8ed0      natts = 1494417160    }  }  out = {    d
={      func = 0x00007fff5912ff08      typfunc = {        fn_addr = 0x000000010786ac18 (plpython3.so`PLy_CSreceive +
360
 
at plpy_spi.c:455)        fn_oid = 570846544        fn_nargs = 32714        fn_strict = '\0'        fn_retset = '\0'
   fn_stats = '\x80'        fn_extra = 0x000000005912fce0        fn_mcxt = 0x0000000106d4d437        fn_expr =
0x00007fca2206ce30     }      typtransform = {        fn_addr = 0x00007fca22062f90        fn_oid = 0        fn_nargs =
0       fn_strict = '\0'        fn_retset = '\0'        fn_stats = '\0'        fn_extra = 0xffffffdc22066c20
fn_mcxt= 0x0000000000000000        fn_expr = 0x00007fca22066f60      }      typoid = 3756919206      typmod =
-754934605     typioparam = 1494416704      typbyval = '\xff'      typlen = 0      typalign = '^'      elm =
0x00007fff5912fd10   }    r = {      atts = 0x00007fff5912ff08      natts = 126266392    }  }  is_rowtype = 0
typ_relid= 0  typrel_xmin = 570847072  typrel_tid = {    ip_blkid = (bi_hi = 32714, bi_lo = 0)    ip_posid = 36408  }
mcxt= 0x000000012206c6f0
 
}
(lldb)

-- 
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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. haswrong type