Update future-tense comments in README to present tense. Noted by

Neil Conway.

src/backend/storage/buffer/README

@@ -1,4 +1,4 @@
-$Header: /cvsroot/pgsql/src/backend/storage/buffer/README,v 1.3 2001/09/29 04:02:22 tgl Exp $
+$Header: /cvsroot/pgsql/src/backend/storage/buffer/README,v 1.4 2003/10/31 22:48:08 tgl Exp $
 
 Notes about shared buffer access rules
 --------------------------------------
@@ -79,20 +79,19 @@ it won't be able to actually examine the page until it acquires shared
 or exclusive lock.
 
 
-As of 7.1, the only operation that removes tuples or compacts free space is
+VACUUM FULL ignores rule #5, because it instead acquires exclusive lock at
-(oldstyle) VACUUM.  It does not have to implement rule #5 directly, because
+the relation level, which ensures indirectly that no one else is accessing
-it instead acquires exclusive lock at the relation level, which ensures
+pages of the relation at all.
-indirectly that no one else is accessing pages of the relation at all.
 
-To implement concurrent VACUUM we will need to make it obey rule #5 fully.
+Plain (concurrent) VACUUM must respect rule #5 fully.  Obtaining the
-To do this, we'll create a new buffer manager operation
+necessary lock is done by the bufmgr routine LockBufferForCleanup().
-LockBufferForCleanup() that gets an exclusive lock and then checks to see
+It first gets an exclusive lock and then checks to see if the shared pin
-if the shared pin count is currently 1.  If not, it releases the exclusive
+count is currently 1.  If not, it releases the exclusive lock (but not the
-lock (but not the caller's pin) and waits until signaled by another backend,
+caller's pin) and waits until signaled by another backend, whereupon it
-whereupon it tries again.  The signal will occur when UnpinBuffer
+tries again.  The signal will occur when UnpinBuffer decrements the shared
-decrements the shared pin count to 1.  As indicated above, this operation
+pin count to 1.  As indicated above, this operation might have to wait a
-might have to wait a good while before it acquires lock, but that shouldn't
+good while before it acquires lock, but that shouldn't matter much for
-matter much for concurrent VACUUM.  The current implementation only
+concurrent VACUUM.  The current implementation only supports a single
-supports a single waiter for pin-count-1 on any particular shared buffer.
+waiter for pin-count-1 on any particular shared buffer.  This is enough
-This is enough for VACUUM's use, since we don't allow multiple VACUUMs
+for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
-concurrently on a single relation anyway.
+single relation anyway.