From 4240d2bffd21a21869a73139bdd63a0bd1f8717b Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 31 Oct 2003 22:48:08 +0000 Subject: [PATCH] Update future-tense comments in README to present tense. Noted by Neil Conway. --- src/backend/storage/buffer/README | 33 +++++++++++++++---------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/src/backend/storage/buffer/README b/src/backend/storage/buffer/README index a2861b8db9..a5d0c926de 100644 --- a/src/backend/storage/buffer/README +++ b/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 -(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.