Re: xlog location arithmetic

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The main actual simplification would be in getting rid of the "hole"
>> at the end of each 4GB worth of WAL, cf this bit in xlog_internal.h:
>> If we can't get rid of that and have a continuous 64-bit WAL address
>> space then it's unlikely we can actually simplify any logic.
>> ...
>> Now, doing that doesn't break the naming convention exactly; what it
>> changes is that there will be WAL files numbered xxxFFFF (for some
>> number of trailing-1-bits I'm too lazy to work out at the moment) where
>> before there were not. So the question really is how much external code
>> there is that is aware of that specific noncontiguous numbering behavior
>> and would be broken if things stopped being that way.

> A page header contains WAL location, so getting rid of "hole" seems to
> break pg_upgrade. No?

No, why would it do that? The meaning and ordering of WAL addresses is
the same as before. The only difference is that after the upgrade, the
system will stop skipping over 16MB of potentially usable WAL addresses
at the end of each subsequently-used 4GB of space. The holes before
the switchover point are still holes, but that doesn't matter.

regards, tom lane