Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
От | Brent Verner |
---|---|
Тема | Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha) |
Дата | |
Msg-id | 20001227040611.A1562@rcfile.org обсуждение исходный текст |
Ответ на | Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
|
Список | 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 по дате отправления: