Re: [HACKERS] equal: don't know whether nodes of type 600 are equal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jwieck(at)debis(dot)com (Jan Wieck)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] equal: don't know whether nodes of type 600 are equal
Date: 1999-02-07 17:44:38
Message-ID: 5054.918409478@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jwieck(at)debis(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-02-07 18:03:21 Re: [HACKERS] Problems with >2GB tables on Linux 2.0
Previous Message Jan Wieck 1999-02-07 17:30:43 v6.4.3 ?