From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why we really need timelines *now* in PITR |
Date: | 2004-07-19 23:58:19 |
Message-ID: | 1452.1090281499@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-20 00:19:58 | Re: Point in Time Recovery |
Previous Message | Simon Riggs | 2004-07-19 23:28:02 | Re: Why we really need timelines *now* in PITR |