On Fri, Jun 10, 2011 at 01:20:25AM -0400, Robert Haas wrote: > On Thu, Jun 9, 2011 at 8:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Fetter <da...@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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers