Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha) - Mailing list pgsql-hackers

From Brent Verner
Subject Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
Date
Msg-id 20001227040611.A1562@rcfile.org
Whole thread Raw
In response to Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
List pgsql-hackers
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <brent@rcfile.org> writes:
| > | Please apply it locally and let me know what you find.
| 
| > what I'm seeing now is much the same.
| 
| Drat.  More to do, then.
| 
| > i've been in circles trying to figure out where fcinfo->arg is filled.
| > can you point me toward that?
| 
| See src/backend/utils/fmgr/README and src/backend/utils/fmgr/fmgr.c.
| But fmgr is probably only the carrier of disease, not the source...

ok, I've tracked this further (in the right direction I hope:).

these are the steps leading up the the assignment of the fscked
fcache->fcinfo.arg[i] at execQual.c:603, which is what will eventually
blow up ExecEvalFieldSelect.


Breakpoint 4, ExecMakeFunctionResult (fcache=0x14014e700,    arguments=0x14014c850, econtext=0x140127ae0,
isNull=0x14014e390"",    isDone=0x11fffde78) at execQual.c:652
 
652             if (fcache->fcinfo.nargs > 0 && !fcache->argsValid)
(gdb) print fcache->fcinfo
$56 = {flinfo = 0x14014e700, context = 0x0, resultinfo = 0x14014e7d0,  isnull = 0 '\000', nargs = 1, arg = {0 <repeats
16times>},  argnull = '\000' <repeats 15 times>}
 
(gdb) cont
Breakpoint 6, ExecEvalVar (variable=0x14014c820, econtext=0x140127ae0,    isNull=0x14014e7c0 "") at execQual.c:298
298             switch (variable->varno)
(gdb) print *variable
$57 = {type = T_Var, varno = 65001, varattno = 1, vartype = 21220,  vartypmod = 8, varlevelsup = 0, varnoold = 1,
varoattno= 0}
 
(gdb) print *econtext
$58 = {type = T_ExprContext, ecxt_scantuple = 0x14014cc58,  ecxt_innertuple = 0x0, ecxt_outertuple = 0x14014cc58,
ecxt_per_query_memory= 0x1400e6370, ecxt_per_tuple_memory = 0x1400e66a0,  ecxt_param_exec_vals = 0x0,
ecxt_param_list_info= 0x0,  ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
 
(gdb) break 313
(gdb) cont
(gdb) print *slot
$60 = {type = T_TupleTableSlot, val = 0x14014e430, ttc_shouldFree = 0 '\000',  ttc_descIsNew = 1 '\001',
ttc_tupleDescriptor= 0x14014ded0, ttc_buffer = 0}
 
(gdb) break 353
(gdb) cont
(gdb) print *heapTuple
$73 = {t_len = 48, t_self = {ip_blkid = {bi_hi = 65535, bi_lo = 65535},    ip_posid = 0}, t_tableOid = 0, t_datamcxt =
0x1400e6370, t_data = 0x14014e450}
 
(gdb) print attnum
$74 = 1
(gdb) print *tuple_type
$75 = {natts = 2, attrs = 0x14014df00, constr = 0x0}
(gdb) print isNull
$76 = (bool *) 0x14014e7c0 ""
(gdb) break 359
(gdb) cont
# after heap_getattr, we have the smashed value.
(gdb) print result
$79 = 303


is this nearing the problem, or still simply witnessing symptoms?
 brent 'delirious from sleep dep.'



pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: GEQO status?
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Inheritance is a security loophole!