Re: [HACKERS] equal: don't know whether nodes of type 600 are equal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] equal: don't know whether nodes of type 600 are equal
Date
Msg-id 5054.918409478@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] equal: don't know whether nodes of type 600 are equal  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] equal: don't know whether nodes of type 600 are equal
Re: [HACKERS] equal: don't know whether nodes of type 600 are equal
List pgsql-hackers
jwieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> I think the real problem is that the EXCEPT/INTERSECT code is dependent
>> on rewrite work that is not being done in the EXPLAIN path, and that
>> we need to fix that underlying problem rather than patching the symptom.

>     I  added  the  call  to QueryRewrite() in ExplainQuery() some
>     time ago. So the comment  in  ExplainOneQuery()  isn't  right
>     (and I should have removed that).

ttest=> select 1 union select 2;
?column?
--------      1      2
(2 rows)

ttest=> explain select 1 union select 2;
ERROR:  copyObject: don't know how to copy 604
ttest=>

This error is coming from inside the planner (specifically union_planner).
Obviously there's *something* different about the context in which the
planner is invoked for EXPLAIN.

It looks to me like the problem is that some rewrite code got placed in
pg_parse_and_plan() in postgres.c --- there is some UNION-handling stuff
going on *after* the call to QueryRewrite(), and evidently that stuff
is not duplicated in the EXPLAIN case.  Probably the right fix is to
move all that logic inside QueryRewrite() --- but I don't want to touch
it without confirmation from someone who knows the parser/planner
better.

Some quick checks with gdb show union_planner() being invoked only once
when the query is executed for real, but recursively when using EXPLAIN
... and it's the recursive call that is throwing the error:

#0  elog (lev=-1, fmt=0x2ef20 "copyObject: don't know how to copy %d")   at elog.c:79
#1  0xae994 in copyObject (from=0x400a5028) at copyfuncs.c:1870
#2  0xae93c in copyObject (from=0x400a5250) at copyfuncs.c:1859
#3  0xc7888 in new_unsorted_tlist (targetlist=0xffffffff) at tlist.c:314
#4  0xc03a0 in union_planner (parse=0x400a5028) at planner.c:110
#5  0xc40d4 in plan_union_queries (parse=0x400a53b8) at prepunion.c:146
#6  0xc03f0 in union_planner (parse=0x400a53b8) at planner.c:131
#7  0xc0320 in planner (parse=0x400a53b8) at planner.c:80
#8  0x8dc64 in ExplainOneQuery (query=0x400a53b8, verbose=0 '\000', dest=604)   at explain.c:92
#9  0x8dc24 in ExplainQuery (query=0x400a5670, verbose=0 '\000', dest=Remote)   at explain.c:76
#10 0x1012e8 in ProcessUtility (parsetree=0x400a52d8, dest=Remote)   at utility.c:781
#11 0xfeba0 in pg_exec_query_dest (   query_string=0x7b0342b0 "explain select a from tt union select a from tt;",
dest=Remote,aclOverride=92 '\\') at postgres.c:819
 
#12 0xfe9f8 in pg_exec_query (   query_string=0xffffffff <Address 0xffffffff out of bounds>)   at postgres.c:711
#13 0xffbfc in PostgresMain (argc=316064, argv=0x51, real_argc=5,   real_argv=0x40002b10) at postgres.c:1664

I wonder whether union_planner() is even really needed anymore given the
rewrite stuff ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: v6.4.3 ?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Problems with >2GB tables on Linux 2.0