out of date bufmgr README - Mailing list pgsql-hackers

From Neil Conway
Subject out of date bufmgr README
Date
Msg-id 1067638555.365.8.camel@tokyo
Whole thread Raw
Responses Re: out of date bufmgr README
List pgsql-hackers
While reading through src/backend/storage/buffer/README, I noticed that
the following text seems to no longer be correct:
       As of 7.1, the only operation that removes tuples or compacts       free space is (oldstyle) VACUUM.  It does
nothave to implement       rule #5 directly, because it instead acquires exclusive lock at       the relation level,
whichensures indirectly that no one else is       accessing pages of the relation at all.              To implement
concurrentVACUUM we will need to make it obey rule       #5 fully. To do this, we'll create a new buffer manager
operationLockBufferForCleanup() that gets an exclusive lock and       then checks to see if the shared pin count is
currently1.  If       not, it releases the exclusive lock (but not the caller's pin)       and waits until signaled by
anotherbackend, whereupon it tries       again.  The signal will occur when UnpinBuffer decrements the       shared pin
countto 1.  As indicated above, this operation might       have to wait a good while before it acquires lock, but that
    shouldn't matter much for concurrent VACUUM.  The current       implementation only supports a single waiter for
pin-count-1on       any particular shared buffer. This is enough for VACUUM's use,       since we don't allow multiple
VACUUMsconcurrently on a single       relation anyway.       
 
Could someone who's aware of the bufmgr changes made for 7.2's lazy
VACUUM comment on how this should be updated?

-Neil




pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: 7.4RC1 planned for Monday
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: Experimental patch for inter-page delay in VACUUM