Thanks for the response and the pg_xlogdump tip.
Dave
> On May 20, 2016, at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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