Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

> 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


pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group