bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views)

From: Joe Conway <mail(at)joeconway(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Kris Jurka <jurka(at)ejurka(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views)
Date: 2002-12-05 22:29:28
Message-ID: 3DEFD348.7000708@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2002-12-05 23:20:54 Re: Bug #837: Unable to use LATIN9 (=ISO-8859-15) encoding
Previous Message pgsql-bugs 2002-12-05 21:08:22 Bug #838: SSL problems in 7.3