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

t-ishii@sra.co.jp writes:
> Interesting thing is that 6.5.x does not have the problem. Is it new
> one for 7.0.x?

I think the bug has been there for a long time.  It is easier to see
in 7.0.2 because VACUUM will now check for nonzero refcount on *all*
pages of the relation.  Formerly, it only checked pages that it was
about to actually truncate from the relation.  So it's possible for
an unreleased pin on a page to go unnoticed in 6.5 but generate a
complaint in 7.0.

Now that I look closely, I see that VACUUM still has a problem with
this in current sources: it only calls FlushRelationBuffers() if it
needs to shorten the relation.  So pinned pages will not be reported
unless the file gets shortened by at least one page.  This is a bug
because it means that pg_upgrade still can't trust VACUUM to ensure
that all on-row status bits are correct (see comments for
FlushRelationBuffers).  I will change it to call FlushRelationBuffers
always.

> I remember that you have fixed some refcount leaks in 6.5.x. Could you
> tell me any examples to demonstrate the cases in 6.5.x, those are
> supposed to be fixed in 7.0.x?

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.
  * SQL functions returning sets could leak even without any elog(),
    if the entire set result was not read for some reason.
There were probably some non-SQL-function cases that got fixed along the
way, but I don't have any concrete examples.  See the pghacker threads
    Anyone understand shared buffer refcount mechanism?
    Progress report: buffer refcount bugs and SQL functions
from September 1999 for more info.

            regards, tom lane