Re: Why we really need timelines *now* in PITR - Mailing list pgsql-hackers

On Tue, 2004-07-20 at 00:58, Tom Lane wrote: 
> Simon Riggs <simon@2ndquadrant.com> writes:
> > where the default is <notarget> and if you specify a target, the default
> > target_in_timeline is <latest>.
> 
> I think actually the default target has to be the timeline ID found in
> pg_control -- otherwise you get weird behavior in the plain crash
> recovery, non-PITR case.

Yes, I was talking about recovery.conf only

So, overall there would be 5 recovery modes with 4 levels of default:

Summarised in the table, also showing what set of actions/parameters we
need to specify to invoke that mode...

----------------SPECIFIED ITEMs
MODE        recovery.conf     rec_target*     target_in_timeline
crash recovery
- up to 7.4-------------no------no--------------no
archive recovery 
- current end-----------yes-----no--------------no
- current target (*)----yes-----yes-------------no current timeline
- other target (*)------yes-----either----------yes, = 'latest' latest timeline
- other target (*)------yes-----either----------yes, = '<value>' other timeline

(*) these operations cause a new timeline to be created

More verbosely (not numbered because they're not a sequence or
progression)

- if no recovery.conf is present we do crash recovery to end of logs on
pg_control timeline (i.e. current) 

- if recovery.conf is present and we do not specify a target we do
archive recovery to end of logs on pg_control timeline (i.e. current) 

- if recovery.conf is present and we specify a target, but no timeline,
then we do archive recovery on the pg_control timeline only, and assume
that the target was supposed to be on this, even if we don't find it

- if recovery.conf is present and we specify a timeline of literally
'latest' (without having to know what that is) - then we search archive
for the latest history file, then we do archive recovery from the
pg_control timeline to the latest timeline as specified in the latest
history file. If we specify a target, then this is searched for on
whatever timeline we're on as we rollforward.

- if recovery.conf is present and we specify a timeline - then we search
archive for that history file, then we do archive recovery from the
pg_control timeline to the specified timeline as shown in that history
file. If we specify a target, then this is searched for on whatever
timeline we're on as we rollforward.

> > I don't like the name target_in_timeline,
> 
> Agreed, but I don't have a better name offhand for it.  The point I was
> making is that we seem to be using "target" to mean a point-in-time
> stopping target.  But you might be interested in going to the end of
> timeline N and so there's not a "target" in that sense.  That's why I
> was wanting to avoid using the term "target" for the desired timeline.
> But maybe there's not a better word.

how about?

end_at_timeline

which is more neutral towards the idea of whether a target has been
specified or not...


Another thing I note is that archive_status .ready messages are written
for all restored xlog files (rather than .done messages). That seems to
cause the archive to be completely overwritten when recovery is
complete. Is that part of the plan for timelines also. Not sure I
understand that...


Best Regards, Simon Riggs