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

"Pedro J. Lobo" <pjlobo(at)euitt(dot)upm(dot)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