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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: Important 7.0.* fix to ensure buffers are released
Date: 2000-09-02 16:37:56
Message-ID: 1174.967912676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

t-ishii(at)sra(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-09-02 16:40:58 Re: A fine point about OUTER JOIN semantics
Previous Message Thomas Lockhart 2000-09-02 16:31:11 (Slightly) broken makefiles

Browse pgsql-patches by date

  From Date Subject
Next Message t-ishii 2000-09-04 01:04:16 Re: [PATCHES] Important 7.0.* fix to ensure buffers are released
Previous Message Alfred Perlstein 2000-09-02 09:17:46 (mode_t) 0077 -> S_IRWXG|S_IRWXO