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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
