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: