You move on to the next buffer header, BH 330. You examine the buffer header and discover it is a dirty buffer with a touch count of 1, which does not meet the default popularity threshold of 2. So, you move the buffer header to the LRU chain's write list. After you complete the move, you check the dirty list length to ensure it is less than _db_large_dirty_queue. The dirty list is only 6, which is less than the common default of 25, so you do not tell the database writer to write its write list.

Now suppose you have scanned more than _db_writer_max_scan_pct buffer headers. If so, you would be very frustrated. You would have consumed a lot of CPU and held the LRU chain latch for a relatively long time. Suppose you have scanned more than this threshold. You now stop scanning, release the LRU chain latch, tell the database writer to free up some buffers, post the wait event free buffer waits, and patiently wait for 10 ms. The really interesting thing is that while you are screaming "free buffer wait!" for 10 ms, the database writer is busy writing dirty buffers to disk, making them free, and then inserting them back into the LRU end of the LRU chain.

Now that you've waited 10 ms, you wake up, acquire the LRU chain latch again, and start your search at the beginning-at the LRU end of your LRU chain. There is now a very high likelihood an unpopular free buffer is waiting there for you to replace. And there is! You pin the buffer header, release the LRU latch, update the buffer header, appropriately move the buffer header in the CBC structure so other processes can find the block you're bringing into the cache, replace the free buffer with the block you read from disk, and unpin the buffer header.