Re: [HACKERS] Postgres dies in the rules regression test (64-bit problem)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Postgres dies in the rules regression test (64-bit problem)
Дата
Msg-id 10564.929048028@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Postgres dies in the rules regression test (64-bit problem)  ("Pedro J. Lobo" <pjlobo@euitt.upm.es>)
Ответы Re: [HACKERS] Postgres dies in the rules regression test (64-bit problem)  ("Pedro J. Lobo" <pjlobo@euitt.upm.es>)
Список pgsql-hackers
"Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
> #0  replace_opid (oper=0x4015aad0) at nodeFuncs.c:95
> #1  0x1201208b0 in fix_opid (clause=0x14015aaa0) at clauses.c:554

> (gdb) p *((Expr *) clause)
> $3 = {type = T_Expr, typeOid = 23, opType = OP_EXPR, oper = 0x4015aad0, 
>   args = 0x14015ab30}

> I don't know if ((Expr*) clause)->oper should point to itself as it seems
> to do,

It shouldn't ever point to itself, but it looks to me like it's not ---
the low order bits of clause are ...aaa0 and oper is ...aad0.

> but certainly its value is passed though an int variable and is
> truncated.

Looks that way doesn't it :-(.  I did some quick scratching around in
the sources and couldn't find any obvious mistakes of that ilk.  Most of
the code that touches Oper nodes would have been exercised heavily long
before we get to the rules regression test, so I'm not sure what to think.

> If someone points me to the right place to look, I can play a bit more
> with gdb and try to find the cause.

The Expr node was presumably made by make_op() in
backend/parser/parse_oper.c, although the tree might have been copied at
least once using the functions in backend/nodes/copyfuncs.c.  Good luck!
        regards, tom lane


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

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] 6.5 Release date
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] 6.5 Release date