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?


# 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 '
  key           alias for $1;
  row           record;
  for row in select a, b from t1 loop
        if row.a = key then
          return row.b;
        end if;
  end loop;
  return null;
' language plpgsql;

create function f2 (integer) returns text as '
  key           alias for $1;
  result        record;
  tmp           record;
  select 5 as a, f1 as b into result from f1(key);
  return result.b;
' 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

Reply via email to