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

Поиск
Список
Период
Сортировка
От Joe Conway
Тема bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views)
Дата
Msg-id 3DEFD348.7000708@joeconway.com
обсуждение исходный текст
Ответ на Re: Explain analyze gives bogus varno for dblink views  (Kris Jurka <books@ejurka.com>)
Ответы Re: bogus varno EXPLAIN bug (was Re: Explain analyze gives bogus varno for dblink views)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: pgsql-bugs@postgresql.org
Дата:
Сообщение: Bug #838: SSL problems in 7.3
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Bug #837: Unable to use LATIN9 (=ISO-8859-15) encoding