Re: PreallocXlogFiles

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> I would like to remove PreallocXlogFiles on the basis that it is dead,
> or at least pointless code.

It could stand improvement I'm sure, but it's not pointless,
particularly not when you have archive mode turned on and so dead xlog
segments can't necessarily be recycled immediately. There's no
guarantee that there are very many segments available to be recycled
when a checkpoint happens, and so if you don't do some preallocation
you may find foreground processes forced to do the work instead when
they run out of forward xlog space.

If you assume a reasonably steady flow of xlog traffic and no
significant archiving delays, then you can see that the system settles
into a steady state where at each checkpoint about the same number of
old WAL files get rotated around to become forward xlog space, and
indeed there's little need for PreallocXlogFiles because MoveOfflineLogs
does all the heavy lifting.

However, I'm not at all convinced that this analysis holds up with
bursty traffic or when the archiver is delaying rotation of old xlogs.
If the number of physical WAL files needs to grow and shrink because
of such effects, then PreallocXlogFiles is the only thing that can
prevent foreground processes from having to do the work that should
be handled by the checkpointer.

I wonder whether we should not put back the preallocated-files GUC
parameter that Bruce took out a release or two back. PreallocXlogFiles
made a lot more sense back when that parameter existed.

regards, tom lane