> 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 like
> select 1/0;
> inside the function.
Oh, I see.
> > 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.
Agreed.
> > 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...
Understood.
--
Tatsuo Ishii
