Dave Stibrany <dstibrany@gmail.com> writes:
> There are 98 WAL segments in the directory currently.
> From the documentation, I understand that the number of WAL files can go as
> high as (3 * checkpoint_segments + 1) segment files, which would be 97 in
> my case, but I seem to be consistently at this number or even higher
> (sometimes over 110 files) and I don't think I've ever seen the directory
> smaller than ~97 segment files.
I don't believe there's any aggressive attempt to remove segment files
after transient peak usage (what happens to them instead is explained
below). If you had many times the expected number of segments, I'd be
worried, but these numbers sound pretty normal to me.
> Regarding the ordering of segments, my understanding is that segment
> 0000012000003720000008B would be written to after 00000012000003720000008A,
> but the timestamps (14:59 and 15:06, respectively) appear to show
> otherwise. There are several cases like this. Does this mean that
> 00000012000003720000008A has newer WAL records than
> 00000012000003720000008B??
No, it probably means that neither one has been written at all yet.
Typically, when a WAL segment is deemed no longer needed, the file isn't
physically removed but is merely renamed into place as a future segment.
The idea is to reduce unnecessary filesystem work as we create and delete
WAL segments. You could check this out if you have pg_xlogdump at hand,
by seeing whether the WAL file's first page header claims to belong to the
segment indicated by the file name, or to some much-older segment.
regards, tom lane