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

From Tom Lane
Subject Re: Why we really need timelines *now* in PITR
Date
Msg-id 1452.1090281499@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why we really need timelines *now* in PITR  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Why we really need timelines *now* in PITR  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> I think we're heatedly agreeing again.

Yeah, I think so.  I'll get started on this tomorrow.

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

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

> ...we definitely need an offline-log inspection tool, don't we? 
> Next month...

Yeah.  When you get started, I have a toy tool I've been using for
awhile that might serve as a starting point.  (I'm going to have to
whack it around for timelines so there's little point in attaching
it right now...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Why we really need timelines *now* in PITR
Next
From: Tom Lane
Date:
Subject: Re: Point in Time Recovery