Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitdfcd9cb

Browse files
committed
Cover heap_page_prune_opt()'s cleanup lock tactic in README.
Jeff Janes, reviewed by Jim Nasby.
1 parentc7e27be commitdfcd9cb

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

Lines changed: 14 additions & 12 deletions
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)

[8]ページ先頭

©2009-2025 Movatter.jp