Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> The point is that in general, the 16 MiB figure is correct, but in
> pathological cases there can be up to two WAL segments on disk per
> checkpoint_segment, so 32 MiB.
The reason for this is that after a checkpoint finishes, we recycle
WAL files up to the *previous* checkpoint --- so just before the
next checkpoint, you've got 2X the checkpoint spacing worth of WAL.
Add some slop for corner cases, and you arrive at the documentation's
statement that you may have as many as 2*checkpoint_segments+1
segments of WAL.
The main reason for wanting the previous checkpoint kept around is
so that we aren't dead in the water if the primary checkpoint is
unreadable --- we back up to the prior checkpoint and replay from
that. I'm not certain how important that really is; it was part of
Vadim's original design for WAL and no one ever particularly
questioned it.
regards, tom lane