mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-21 08:29:39 +08:00
Update future-tense comments in README to present tense. Noted by
Neil Conway.
This commit is contained in:
parent
47309464e4
commit
4240d2bffd
@ -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
|
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.
|
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.
|
||||||
|
Loading…
Reference in New Issue
Block a user