
> 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.
 
> Should we implement timelines?

Yes :-)

Andreas

Wed, 7 Jul 2004 15:17:31 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Point in Time Recovery
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



Thu, 08 Jul 2004 01:17:47 +0100
Simon Riggs <simon@2ndquadrant.com>
Re: Point in Time Recovery
On Thu, 8 Jul 2004, Simon Riggs wrote:

> 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.

I'd disagree on that. Knowing what exactly happens when recovering the
database is a must. It makes people feel more safe about the process. This
is because the software doesn't do things you wouldn't expect.

On Oracle e.g. you create a new database incarnation when you recover a
database (incomplete). Which means your System Change Number and your Log
Sequence is reset to 0.
Knowing this is crucial because you otherwise would wonder "Why is it
doing that? Is this a bug or a feature?"

Just my 2ct :-))

Greetings, Klaus

-- 
Full Name   : Klaus Naumann     | (http://www.mgnet.de/) (Germany)
Phone / FAX : ++49/177/7862964  | E-Mail: (kn@mgnet.de)

Thu, 8 Jul 2004 08:57:49 +0200 (CEST)
spock@mgnet.de
Re: Point in Time Recovery
On Thu, 2004-07-08 at 07:57, spock@mgnet.de wrote:
> On Thu, 8 Jul 2004, Simon Riggs wrote:
> 
> > 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.
> 
> I'd disagree on that. Knowing what exactly happens when recovering the
> database is a must. It makes people feel more safe about the process. This
> is because the software doesn't do things you wouldn't expect.
> 
> On Oracle e.g. you create a new database incarnation when you recover a
> database (incomplete). Which means your System Change Number and your Log
> Sequence is reset to 0.
> Knowing this is crucial because you otherwise would wonder "Why is it
> doing that? Is this a bug or a feature?"
> 

OK, will do.

Best regards, Simon Riggs


Thu, 08 Jul 2004 11:42:50 +0100
Simon Riggs <simon@2ndquadrant.com>
Re: Point in Time Recovery