bgwriter配合唤醒
src/backend/storage/buffer/README
代码语言：javascript复制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.- bgwriter旨在write out可能很快被回收的页面，分担backend的工作。
- bgwriter从 nextVictimBuffer 的当前位置（不会改变！）循环向前扫描，寻找脏的、未pin或usage count>0的缓冲区。
- bgwriter pin、write out和release缓冲区。
If we can assume that reading nextVictimBuffer is an atomic action, then
the writer doesn't even need to take buffer_strategy_lock 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
only needs to take the lock long enough to read the variable value, not
while scanning the buffers. (This is a very substantial improvement in
the contention cost of the writer compared to PG 8.0.)- 如果可以假设读取 nextVictimBuffer 是一个原子操作，那bgwriter不需要加buffer_strategy_lock 来寻找要写入的缓冲区
- bgwriter只需要spin锁定每个缓冲区hdr足够长的时间来检查脏位
The background writer takes shared content lock on a buffer while writing it
out (and anyone else who flushes buffer contents to disk must do so too).
This ensures that the page image transferred to disk is reasonably consistent.
We might miss a hint-bit update or two but that isn't a problem, for the same
reasons mentioned under buffer access rules.
As of 8.4, background writer starts during recovery mode when there is
some form of potentially extended recovery to perform. It performs an
identical service to normal processing, except that checkpoints it
writes are technically restartpoints.- bgwriter在写出缓冲区加锁：shared content lock（其他任何将缓冲区内容刷盘也必须这样做）确保传输到磁盘的页面一致。
buffer id 分配流程
