Skip to content

Commit dfcd9cb

Browse files
committed
Cover heap_page_prune_opt()'s cleanup lock tactic in README.
Jeff Janes, reviewed by Jim Nasby.
1 parent c7e27be commit dfcd9cb

File tree

1 file changed

+14
-12
lines changed
  • src/backend/storage/buffer

1 file changed

+14
-12
lines changed

src/backend/storage/buffer/README

+14-12
Original file line numberDiff line numberDiff line change
@@ -81,18 +81,20 @@ it won't be able to actually examine the page until it acquires shared
8181
or exclusive content lock.
8282

8383

84-
Rule #5 only affects VACUUM operations. Obtaining the
85-
necessary lock is done by the bufmgr routine LockBufferForCleanup().
86-
It first gets an exclusive lock and then checks to see if the shared pin
87-
count is currently 1. If not, it releases the exclusive lock (but not the
88-
caller's pin) and waits until signaled by another backend, whereupon it
89-
tries again. The signal will occur when UnpinBuffer decrements the shared
90-
pin count to 1. As indicated above, this operation might have to wait a
91-
good while before it acquires lock, but that shouldn't matter much for
92-
concurrent VACUUM. The current implementation only supports a single
93-
waiter for pin-count-1 on any particular shared buffer. This is enough
94-
for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
95-
single relation anyway.
84+
Obtaining the lock needed under rule #5 is done by the bufmgr routines
85+
LockBufferForCleanup() or ConditionalLockBufferForCleanup(). They first get
86+
an exclusive lock and then check to see if the shared pin count is currently
87+
1. If not, ConditionalLockBufferForCleanup() releases the exclusive lock and
88+
then returns false, while LockBufferForCleanup() releases the exclusive lock
89+
(but not the caller's pin) and waits until signaled by another backend,
90+
whereupon it tries again. The signal will occur when UnpinBuffer decrements
91+
the shared pin count to 1. As indicated above, this operation might have to
92+
wait a good while before it acquires lock, but that shouldn't matter much for
93+
concurrent VACUUM. The current implementation only supports a single waiter
94+
for pin-count-1 on any particular shared buffer. This is enough for VACUUM's
95+
use, since we don't allow multiple VACUUMs concurrently on a single relation
96+
anyway. Anyone wishing to obtain a cleanup lock outside of recovery or a
97+
VACUUM must use the conditional variant of the function.
9698

9799

98100
Buffer Manager's Internal Locking

0 commit comments

Comments
 (0)