On Wed, 2004-07-07 at 14:17, Zeugswetter Andreas SB SD wrote:
> > Well, Tom does seem to have something with regard to StartUpIds. I feel
> > it is easier to force a new timeline by adding a very large number to
> > the LogId IF, and only if, we have performed an archive recovery. That
> > way, we do not change at all the behaviour of the system for people that
> > choose not to implement archive_mode.
>
> Imho you should take a close look at StartUpId, I think it is exactly this
> "large number". Maybe you can add +2 to intentionally leave a hole.
>
> Once you increment, I think it is very essential to checkpoint and double
> check pg_control, cause otherwise a crashrecovery would read the wrong xlogs.
Thanks for your thoughts - you have made me rethink this over some
hours. Trouble is, on this occasion, the other suggestion still seems
the best one, IMVHO.
If we number timelines based upon StartUpId, then there is still some
potential for conflict and this is what we're seeking to avoid.
Simply adding FFFF to the LogId puts the new timeline so far into the
previous timelines future that there isn't any problems. We only
increment the timeline when we recover, so we're not eating up the
numbers quickly. Simply adding a number means that there isn't any
conflict with any normal operations. The timelines aren't numbered
separately, so I'm not introducing a new version of
StartUpID...technically there isn't a new timeline, just a chunk of
geological time between them.
We don't need to mention timelines in the docs, nor do we need to alter
pg_controldata to display it...just a comment in the code to explain why
we add a large number to the LogId after each recovery completes.
Best regards, Simon Riggs
