Re: pg_xlog - files are guaranteed to be sequentialy named? - Mailing list pgsql-general

From Johannes Konert
Subject Re: pg_xlog - files are guaranteed to be sequentialy named?
Date
Msg-id 467051E9.2030802@t3go.de
Whole thread Raw
In response to Re: pg_xlog - files are guaranteed to be sequentialy named?  (Frank Wittig <fw@weisshuhn.de>)
List pgsql-general
Frank Wittig wrote:
>> 24 Hex digits means 24^16 unique file names. Assuming your server saves
>> a WAL file each second (you should review your config it it does) it
>> takes (24^16)/(60*60*24*365)=3.84214066×10^14 years to reach the upper
>> bound.
>>
>
> (..) It has to be 16^24.
> But pg does forge filenames other that that. It uses 2 hex digits to
> count segments. After 256 segments counting starts over and the serial
> is increased by one. The first 8 positions are the time line which I
> will ignore for my new calculation.
>
> So there is an eight hex digits serial for each time line which takes
> 256 segments. So there are 16^8*256 unique file names. If I assume one
> WAL file a second this would reach upper bound (for a single time line)
> after slightly more than 136 years.
>
> Please correct me if my assumptions are wrong. But I would say one can
> rely on serial file names to increase steadily.
>
Thanks for that answer. That was exactly what I could not immediatelly
find mentioned in the documentation.
If it is guaranteed - and I understood your comments this way - that the
naming follows a sequential order, then I agree with you, that this is
enough for a long time.
I was not sure wether or not the naming follows this rule. Of course I
calculated the number of possible filenames before, but as I said, I was
not sure, that Postgresql follows a guaranteed naming convention of
always increasing WAL filenames.
Anyway, this is now for sure and I will rely on that now.
Regards Johannes

pgsql-general by date:

Previous
From: Johannes Konert
Date:
Subject: Re: pg_xlog - files are guaranteed to be sequentialy named?
Next
From: Andrew Sullivan
Date:
Subject: Re: how to enforce index usage with +0