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

Neil Conway.

src/backend/storage/buffer/README

-$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
-(oldstyle) VACUUM.  It does not have to implement rule #5 directly, because
-it instead acquires exclusive lock at the relation level, which ensures
-indirectly that no one else is accessing pages of the relation at all.
+VACUUM FULL ignores rule #5, because it instead acquires exclusive lock at
+the relation level, which ensures 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.
-To do this, we'll create a new buffer manager operation
-LockBufferForCleanup() that gets an exclusive lock and then checks to see
-if the shared pin count is currently 1.  If not, it releases the exclusive
-lock (but not the caller's pin) and waits until signaled by another backend,
-whereupon it tries again.  The signal will occur when UnpinBuffer
-decrements the shared pin count to 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-1 on any particular shared buffer.
-This is enough for VACUUM's use, since we don't allow multiple VACUUMs
-concurrently on a single relation anyway.
+Plain (concurrent) VACUUM must respect rule #5 fully.  Obtaining the
+necessary lock is done by the bufmgr routine LockBufferForCleanup().
+It first gets an exclusive lock and then checks to see if the shared pin
+count is currently 1.  If not, it releases the exclusive lock (but not the
+caller's pin) and waits until signaled by another backend, whereupon it
+tries again.  The signal will occur when UnpinBuffer decrements the shared
+pin count to 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-1 on any particular shared buffer.  This is enough
+for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
+single relation anyway.