rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

Neil Conway.
This commit is contained in:
Tom Lane 2003-10-31 22:48:08 +00:00
parent 47309464e4
commit 4240d2bffd
1 changed files with 16 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
src/backend/storage/buffer/README
View File

@ -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.