While reading through src/backend/storage/buffer/README and looking at the code that it describes, I noticed that the case is wrong for nextVictimBuffer.
It's no big deal really, but the attached trivial patch makes the README match the code. -- Vik
*** a/src/backend/storage/buffer/README --- b/src/backend/storage/buffer/README *************** *** 176,183 **** small limit value) whenever the buffer is pinned. (This requires only the buffer header spinlock, which would have to be taken anyway to increment the buffer reference count, so it's nearly free.) ! The "clock hand" is a buffer index, NextVictimBuffer, that moves circularly ! through all the available buffers. NextVictimBuffer is protected by the BufFreelistLock. The algorithm for a process that needs to obtain a victim buffer is: --- 176,183 ---- buffer header spinlock, which would have to be taken anyway to increment the buffer reference count, so it's nearly free.) ! The "clock hand" is a buffer index, nextVictimBuffer, that moves circularly ! through all the available buffers. nextVictimBuffer is protected by the BufFreelistLock. The algorithm for a process that needs to obtain a victim buffer is: *************** *** 189,196 **** is pinned or has a nonzero usage count, it cannot be used; ignore it and return to the start of step 2. Otherwise, pin the buffer, release BufFreelistLock, and return the buffer. ! 3. Otherwise, select the buffer pointed to by NextVictimBuffer, and ! circularly advance NextVictimBuffer for next time. 4. If the selected buffer is pinned or has a nonzero usage count, it cannot be used. Decrement its usage count (if nonzero) and return to step 3 to --- 189,196 ---- return to the start of step 2. Otherwise, pin the buffer, release BufFreelistLock, and return the buffer. ! 3. Otherwise, select the buffer pointed to by nextVictimBuffer, and ! circularly advance nextVictimBuffer for next time. 4. If the selected buffer is pinned or has a nonzero usage count, it cannot be used. Decrement its usage count (if nonzero) and return to step 3 to *************** *** 254,264 **** Background Writer's Processing The background writer is designed to write out pages that are likely to be recycled soon, thereby offloading the writing work from active backends. To do this, it scans forward circularly from the current position of ! NextVictimBuffer (which it does not change!), looking for buffers that are dirty and not pinned nor marked with a positive usage count. It pins, writes, and releases any such buffer. ! If we can assume that reading NextVictimBuffer is an atomic action, then the writer doesn't even need to take the BufFreelistLock in order to look for buffers to write; it needs only to spinlock each buffer header for long enough to check the dirtybit. Even without that assumption, the writer --- 254,264 ---- The background writer is designed to write out pages that are likely to be recycled soon, thereby offloading the writing work from active backends. To do this, it scans forward circularly from the current position of ! nextVictimBuffer (which it does not change!), looking for buffers that are dirty and not pinned nor marked with a positive usage count. It pins, writes, and releases any such buffer. ! If we can assume that reading nextVictimBuffer is an atomic action, then the writer doesn't even need to take the BufFreelistLock in order to look for buffers to write; it needs only to spinlock each buffer header for long enough to check the dirtybit. Even without that assumption, the writer *************** *** 268,274 **** the contention cost of the writer compared to PG 8.0.) During a checkpoint, the writer's strategy must be to write every dirty buffer (pinned or not!). We may as well make it start this scan from ! NextVictimBuffer, however, so that the first-to-be-written pages are the ones that backends might otherwise have to write for themselves soon. The background writer takes shared content lock on a buffer while writing it --- 268,274 ---- During a checkpoint, the writer's strategy must be to write every dirty buffer (pinned or not!). We may as well make it start this scan from ! nextVictimBuffer, however, so that the first-to-be-written pages are the ones that backends might otherwise have to write for themselves soon. The background writer takes shared content lock on a buffer while writing it
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
