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
