Re: Re: [PATCHES] Important 7.0.* fix to ensure buffers are released

> 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