bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views) - Mailing list pgsql-bugs
From | Joe Conway |
---|---|
Subject | bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views) |
Date | |
Msg-id | 3DEFD348.7000708@joeconway.com Whole thread Raw |
In response to | Re: Explain analyze gives bogus varno for dblink views (Kris Jurka <books@ejurka.com>) |
Responses |
Re: bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views)
|
List | pgsql-bugs |
Kris Jurka wrote: > This behavior is present in 7.3 as well. > > On Thu, 5 Dec 2002, Kris Jurka wrote: >>Using the old < 7.3 version of dblink on 7.4devel gives a >>"get_names_for_var: bogus varno 5" error. I can confirm this both on cvs tip (pulled after noon PST today) and 7.3 stable branch. It is not related to dblink, but rather the backend. Here's a (contrived) script based on Kris's example to trigger it: CREATE TABLE table1 (a int); CREATE TABLE table2 (a int, b int); INSERT INTO table1 (a) VALUES (1); INSERT INTO table2 (a,b) VALUES (1,1); INSERT INTO table2 (a,b) VALUES (1,2); CREATE OR REPLACE FUNCTION func1(int) RETURNS setof int AS ' select a from table2 where a = $1 ' LANGUAGE 'sql' WITH (isstrict); CREATE OR REPLACE FUNCTION func2(int,int) RETURNS int AS ' select $1 * $2 ' LANGUAGE 'sql' WITH (isstrict); CREATE VIEW v1 AS SELECT func2(t1.f1,3) as a FROM (SELECT func1(1) as f1) AS t1; DROP VIEW v2; CREATE VIEW v2 AS SELECT func2(t2.f1,3) as a, func2(t2.f1,5) as b FROM (SELECT func1(1) as f1) AS t2; SELECT * FROM v1,v2 WHERE v1.a=v2.a AND v1.a=3; EXPLAIN ANALYZE SELECT * FROM v1,v2 WHERE v1.a=v2.a AND v1.a=3; Here's a backtrace: #0 elog (lev=20, fmt=0x8211800 "get_names_for_var: bogus varno %d") at elog.c:114 #1 0x0815e53c in get_names_for_var (var=0x82d07ec, context=0xbfffe9c0, schemaname=0xbfffe8b0, refname=0xbfffe8b4, attname=0xbfffe8b8) at ruleutils.c:1806 #2 0x0815e6ed in get_rule_expr (node=0x82d07ec, context=0xbfffe9c0, showimplicit=1 '\001') at ruleutils.c:1938 #3 0x0815eed3 in get_oper_expr (expr=0x0, context=0xbfffe9c0) at ruleutils.c:2282 #4 0x0815e7de in get_rule_expr (node=0x82d0b54, context=0xbfffe9c0, showimplicit=1 '\001') at ruleutils.c:1972 #5 0x0815eed3 in get_oper_expr (expr=0x0, context=0xbfffe9c0) at ruleutils.c:2282 #6 0x0815e7de in get_rule_expr (node=0x82d0b9c, context=0xbfffe9c0, showimplicit=0 '\0') at ruleutils.c:1972 #7 0x0815cfef in deparse_expression (expr=0x82d0b9c, dpcontext=0x0, forceprefix=0 '\0', showimplicit=0 '\0') at ruleutils.c:872 #8 0x080ca75a in show_upper_qual (qual=0x82d1d50, qlabel=0x81df318 "Filter", outer_name=0x5 <Address 0x5 out of bounds>, outer_varno=1, outer_plan=0x0, inner_name=0x819479b "", inner_varno=0, inner_plan=0x0, str=0x82d7668, indent=3, es=0x82e4b58) at explain.c:812 #9 0x080ca01e in explain_outNode (str=0x82d7668, plan=0x82d1d6c, planstate=0x82d4674, outer_plan=0x0, indent=3, es=0x82d7a58) at explain.c:570 #10 0x080c9d3a in explain_outNode (str=0x82d7668, plan=0x82d2098, planstate=0x82d2560, outer_plan=0x0, indent=0, es=0x82d7a58) at explain.c:614 #11 0x080c992b in ExplainOneQuery (query=0x82d7668, stmt=0x82bb9e8, tstate=0x82c06c8) at explain.c:198 #12 0x080c9745 in ExplainQuery (stmt=0x82bb9e8, dest=Remote) at explain.c:102 #13 0x081388a3 in pg_exec_query_string (query_string=0x82bb9e8, dest=Remote, parse_context=0x8287574) at postgres.c:789 #14 0x0813976c in PostgresMain (argc=5, argv=0xbfffee70, username=0x8279f19 "postgres") at postgres.c:2016 #15 0x0811e30e in DoBackend (port=0x8279de8) at postmaster.c:2293 #16 0x0811de7a in BackendStartup (port=0x8279de8) at postmaster.c:1915 #17 0x0811cf9d in ServerLoop () at postmaster.c:1002 #18 0x0811c915 in PostmasterMain (argc=3, argv=0x825cc78) at postmaster.c:781 #19 0x080f930f in main (argc=3, argv=0xbffff7e4) at main.c:209 Note the line: #8 0x080ca75a in show_upper_qual (qual=0x82d1d50, qlabel=0x81df318 "Filter", outer_name=0x5 <Address 0x5 out of bounds>, I'm still trying to understand the root cause, but any pointers would be appreciated. Thanks, Joe
pgsql-bugs by date: