Database block lifecycle

The normal sequence by which a block makes its way through shared memory and either onto (or back onto) disk works like this:

1. A page to hold the database block needed is requested for allocation in the shared buffer cache. If that block already exists in there, no disk read is needed. Otherwise, ask the operating system to read the page into memory. In either case, at this point the page in memory will have its usage count increased, because presumably it's being requested so that it can be used for something. The pgstat_bgwriter.buffers_alloc statistics will be incremented to count this allocation.
2. Changes are made to the block. In the last example, an INSERT created a new row in a new block. You might also UPDATE or DELETE something that changes a block. The block is now dirty.
3. The transaction commits to the WAL. At this point, whether or not the dirty block is written out to the database file on disk in the near future, the information needed to make...