On Tue, Mar 13, 2012 at 12:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> On Sat, Mar 10, 2012 at 5:04 AM, Tom Lane <t...@sss.pgh.pa.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.
Oh, I see. You're right. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
