t-ishii@sra.co.jp writes:
> Am I missing something?
I don't have 6.5.* running anymore to check, but it looked to me like
elog out of an SQL function would result in refcount leaks. But the
elog would have to occur while inside the function's recursive call
to ExecutorRun, so your example (which will detect its error during
query plan setup) doesn't exhibit the problem. Try something likeselect 1/0;
inside the function.
> Interesting thing is that the select in above case produces a
> notice in 7.0.2 (with or without your patches):
Yes, still there in current sources. The leak comes from the fact
that the function's internal SELECT is never shut down because the
function isn't run to completion. This is one of the things I think we
need to fix during querytree redesign. However, 7.0 at least detects
and recovers from the leak, which is more than can be said for 6.5.
> while 6.5.3 does not. Maybe 6.5.3 failes to detect buffer leaks at
> transaction commit time?
In fact it does fail to detect them, in cases like this where the leak
is attributable to an uncompleted query inside a function call. That's
one of the things that was broken about the refcount save/restore
mechanism...
regards, tom lane