|
1 | | -$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.9 2006/03/31 23:32:06 tgl Exp $ |
| 1 | +$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.10 2006/06/08 14:58:33 tgl Exp $ |
2 | 2 |
|
3 | 3 | Notes about shared buffer access rules |
4 | 4 | -------------------------------------- |
@@ -78,11 +78,7 @@ it won't be able to actually examine the page until it acquires shared |
78 | 78 | or exclusive content lock. |
79 | 79 |
|
80 | 80 |
|
81 | | -VACUUM FULL ignores rule #5, because it instead acquires exclusive lock at |
82 | | -the relation level, which ensures indirectly that no one else is accessing |
83 | | -pages of the relation at all. |
84 | | - |
85 | | -Plain (concurrent) VACUUM must respect rule #5 fully. Obtaining the |
| 81 | +Rule #5 only affects VACUUM operations. Obtaining the |
86 | 82 | necessary lock is done by the bufmgr routine LockBufferForCleanup(). |
87 | 83 | It first gets an exclusive lock and then checks to see if the shared pin |
88 | 84 | count is currently 1. If not, it releases the exclusive lock (but not the |
@@ -235,3 +231,9 @@ During a checkpoint, the writer's strategy must be to write every dirty |
235 | 231 | buffer (pinned or not!). We may as well make it start this scan from |
236 | 232 | NextVictimBuffer, however, so that the first-to-be-written pages are the |
237 | 233 | ones that backends might otherwise have to write for themselves soon. |
| 234 | + |
| 235 | +The background writer takes shared content lock on a buffer while writing it |
| 236 | +out (and anyone else who flushes buffer contents to disk must do so too). |
| 237 | +This ensures that the page image transferred to disk is reasonably consistent. |
| 238 | +We might miss a hint-bit update or two but that isn't a problem, for the same |
| 239 | +reasons mentioned under buffer access rules. |