Hello, Joe!
JC> With the current SRF patch, in certain circumstances selecting fromJC> aJC> VIEW produces "Buffer Leak" warnings,
whileselecting from theJC> function itself does not. Also the VIEW returns only one of the two
Selecting from the function produces such a warning when using it with
limit,
but it does not when the function returns less rows than specified in limit
.
e.g.
just_fun=# create table testtab(i integer, v varchar);
CREATE
just_fun=# insert into testtab values(1,'one');
INSERT 16592 1
just_fun=# insert into testtab values(2,'two');
INSERT 16593 1
just_fun=# insert into testtab values(3,'three');
INSERT 16594 1
just_fun=# insert into testtab values(1,'one again');
INSERT 16595 1
just_fun=# create function fun(integer) returns setof testtab as 'select *
from testtab where i= $1;' language 'sql';
just_fun=# select * from fun(1) as fun;i | v
---+-----------1 | one1 | one again
(2 rows)
just_fun=# select * from fun(1) as fun limit 1;
WARNING: Buffer Leak: [050] (freeNext=-3, freePrev=-3, rel=16570/16587,
blockNum=0, flags=0x85, refcount=1 2)i | v
---+-----1 | one
(1 row)
....And there is no warning with "ORDER BY"
just_fun=# select * from fun(1) as fun order by v limit 1;i | v
---+-----1 | one
(1 row)
Hope this info maybe useful to solve the problem.
By the way, could you give an example of C-function returning set?
JC> expected rows. The same SQL function when declared as "...JC> getfoo(int) RETURNS int AS ..." instead of "...
getfoo(int)RETURNSJC> *setof* int AS..." does not produce the warning. Any ideas what IJC> should be focusing on to
track this down? Does anyone have anyJC> favorite troubleshooting techniques for this type of problem?
JC> Thanks,JC> Joe
Thank you for your work in this direction!
With best regards, Valentine Zaretsky
