On Fri, Jun 10, 2011 at 01:20:25AM -0400, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 8:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > David Fetter <david@fetter.org> writes:
> >> The nice people at VMware, where I work, have come up with a small
> >> patch to allow PITR to create a new timeline. This is useful in cases
> >> where you're using filesystem snapshots of $PGDATA which may be old.
> >
> > Huh? We already start a new timeline when doing a non-crash-recovery
> > replay scenario.
> >
> > The code looks pretty confused too, which makes it difficult to
> > reverse-engineer what your point is.
>
> I am guessing that they are taking a filesystem snapshot, and then
> using that to fire up PG. So to PG it looks like a crash recovery,
> but they want a new timeline anyway.
>
> <waves hands>
That's pretty much it. More detail:
Let's imagine we're taking filesystem snapshots each day by whatever
means. We're also archiving xlogs, but only have space for 48 hours'
worth. Now we want to recover to 3 days ago, but there are no WALs
from that time, so we do a crash recovery from the filesystem
snapshot. Doing continuous archiving from this conflicts with the
existing WALs, which we solve by creating a new timeline.
This also allows subsequent PITR to other times on the original
timeline.
Josh B pointed out that since this option to true conflicts with
another option, having both should prevent recovery from even
starting, and I'll work up a patch for this tonight or at latest
tomorrow.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
