On 5/12/2007 4:53 PM, Jan Wieck wrote:
Either calling pg_plan_queries() with needSnapshot=false or saving and
restoring ActiveSnapshot will prevent the backend from dumping core in
the mentioned example, but I am not entirely sure as to which one is the
right solution.
Attached is a self contained example that crashes the current backend.
It took me a moment to figure out exactly how to reproduce it. The
problem occurs when the query that needs replanning is actually a
FOR record IN SELECT ...
that is inside of a nested function call. In that case, the revalidation
of the saved plan actually happens inside of SPI_cursor_open(), which
does not save and restore the ActiveSnapshot. Shouldn't it?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
create table t1 (a integer, b text, primary key (a));
create function f1 (integer) returns text as '
declare
key alias for $1;
row record;
begin
for row in select a, b from t1 loop
if row.a = key then
return row.b;
end if;
end loop;
return null;
end;
' language plpgsql;
create function f2 (integer) returns text as '
declare
key alias for $1;
result record;
tmp record;
begin
select 5 as a, f1 as b into result from f1(key);
return result.b;
end;
' language plpgsql;
insert into t1 values (1, 'one');
insert into t1 values (2, 'two');
select f2(1);
alter table t1 add column c text;
select f2(2);
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
