[ Cc: to hackers list]
> I think the primary problems had to do with recursive calls to
> ExecutorRun, which'd invoke the badly broken buffer refcount save/
> restore mechanism that was present in 6.5 and earlier. This would
> mainly be done by SQL and PL functions that do SELECTs. A couple
> of examples:
> * elog(ERROR) from inside an SQL function would mean that buffer
> refcounts held by the outer scan wouldn't be released. So, eg,
> SELECT sqlfunction(column1) FROM foo;
> was a buffer leak risk.
Following case doesn't produce notices from BlowawayRelationBuffers.
drop table t1;
create table t1(i int);
drop table t2;
create table t2(i int);
insert into t1 values(1);
drop function f1(int);
create function f1(int) returns int as ' select $1 +1; select i from t2;
' language 'sql';
drop table t2;
select f1(i) from t1;
delete from t1;
vacuum t1;
Am I missing something?
> * SQL functions returning sets could leak even without any elog(),
> if the entire set result was not read for some reason.
However, following case produces:
NOTICE: BlowawayRelationBuffers(t1, 0): block 0 is referenced...
as expected.
drop table t1;
create table t1(i int);
insert into t1 values(1);
insert into t1 select i from t1;
insert into t1 select i from t1;
drop function f1(int);
create function f1(int) returns setof int as ' select i from t1;
' language 'sql';
select f1(i) from t1 limit 1 offset 0;
delete from t1;
vacuum analyze t1;
Interesting thing is that the select in above case produces a
notice in 7.0.2 (with or without your patches):
NOTICE: Buffer Leak: [059] (freeNext=-3, freePrev=-3, relname=t1, blockNum=0, flags=0x4, refcount=1 2)
while 6.5.3 does not. Maybe 6.5.3 failes to detect buffer leaks at
transaction commit time?
--
Tatsuo Ishii
