|
1 | | -$Header: /cvsroot/pgsql/src/backend/storage/buffer/README,v 1.3 2001/09/29 04:02:22 tgl Exp $ |
| 1 | +$Header: /cvsroot/pgsql/src/backend/storage/buffer/README,v 1.4 2003/10/31 22:48:08 tgl Exp $ |
2 | 2 |
|
3 | 3 | Notes about shared buffer access rules |
4 | 4 | -------------------------------------- |
@@ -79,20 +79,19 @@ it won't be able to actually examine the page until it acquires shared |
79 | 79 | or exclusive lock. |
80 | 80 |
|
81 | 81 |
|
82 | | -As of 7.1, the only operation that removes tuples or compacts free space is |
83 | | -(oldstyle) VACUUM. It does not have to implement rule #5 directly, because |
84 | | -it instead acquires exclusive lock at the relation level, which ensures |
85 | | -indirectly that no one else is accessing pages of the relation at all. |
| 82 | +VACUUM FULL ignores rule #5, because it instead acquires exclusive lock at |
| 83 | +the relation level, which ensures indirectly that no one else is accessing |
| 84 | +pages of the relation at all. |
86 | 85 |
|
87 | | -To implement concurrent VACUUM we will need to make it obey rule #5 fully. |
88 | | -To do this, we'll create a new buffer manager operation |
89 | | -LockBufferForCleanup() that gets an exclusive lock and then checks to see |
90 | | -if the shared pin count is currently 1. If not, it releases the exclusive |
91 | | -lock (but not the caller's pin) and waits until signaled by another backend, |
92 | | -whereupon it tries again. The signal will occur when UnpinBuffer |
93 | | -decrements the shared pin count to 1. As indicated above, this operation |
94 | | -might have to wait a good while before it acquires lock, but that shouldn't |
95 | | -matter much for concurrent VACUUM. The current implementation only |
96 | | -supports a single waiter for pin-count-1 on any particular shared buffer. |
97 | | -This is enough for VACUUM's use, since we don't allow multiple VACUUMs |
98 | | -concurrently on a single relation anyway. |
| 86 | +Plain (concurrent) VACUUM must respect rule #5 fully. Obtaining the |
| 87 | +necessary lock is done by the bufmgr routine LockBufferForCleanup(). |
| 88 | +It first gets an exclusive lock and then checks to see if the shared pin |
| 89 | +count is currently 1. If not, it releases the exclusive lock (but not the |
| 90 | +caller's pin) and waits until signaled by another backend, whereupon it |
| 91 | +tries again. The signal will occur when UnpinBuffer decrements the shared |
| 92 | +pin count to 1. As indicated above, this operation might have to wait a |
| 93 | +good while before it acquires lock, but that shouldn't matter much for |
| 94 | +concurrent VACUUM. The current implementation only supports a single |
| 95 | +waiter for pin-count-1 on any particular shared buffer. This is enough |
| 96 | +for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a |
| 97 | +single relation anyway. |
0 commit comments