Re: WAL segments (names) not in a sequence

On Thu, May 23, 2013 at 5:01 PM, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>> I think these are the WAL files that were preallocated by WAL
>> recycling but have not
>> been used yet.
>>
>>> # WAL after wal_level changed from 'minimal' to 'hot_standby'
>>>
>>> -rw------- 1 postgres postgres 16777216 May 21 12:27 000000010000000E0000007B
>>> -rw------- 1 postgres postgres 16777216 May 21 12:35 000000010000000E0000007C
>>> -rw------- 1 postgres postgres 276 May 21 12:35
>>> 000000010000000E0000007C.00000020.backup
>>> -rw------- 1 postgres postgres 16777216 May 21 14:53 000000010000000E0000007D
>>> -rw------- 1 postgres postgres 16777216 May 21 14:53 000000010000000E0000007E
>>> -rw------- 1 postgres postgres 16777216 May 21 14:53 000000010000000E0000007F
>>> -rw------- 1 postgres postgres 16777216 May 21 14:53 000000010000000E00000080
>>
>> These are the WAL files that you now used. So I don't think that WAL
>> file sequence rewound
>> in this case.
>>
>
> Can pre-allocation go that further? for example, assuming
> 000000010000000E00000080 is currently being used, then is it possible
> that a segment named/numbered 00000001000000100000007E (which does
> exist in his pg_xlog as he reported in pgsql-admin thread) is
> pre-allocated already?

Yes, if it's so old that it's no longer required for the crash recovery.

WAL recycling is performed by checkpoint. Checkpoint always checks
whether there are
WAL files no longer required for crash recovery, IOW, WAL files which
were generated
before the prior checkpoint happened, and then if they are found,
checkpoint tries to recycle
them.

> I think we could ask the user the latest value of "select
> pg_xlogfile_name(pg_xlog_current_location())".

Yep.

Regards,

--
Fujii Masao