Re: PITR and warm standby setup questions

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dhaval Shah <dhaval(dot)shah(dot)m(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Mason Hale <masonhale(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: PITR and warm standby setup questions
Date: 2007-11-14 18:44:09
Message-ID: 200711141844.lAEIi9X19821@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dhaval Shah wrote:
> I am on 8.2 production and it will be difficult to upgrade to 8.3. Is
> it possible to backport the "%r" fix from 8.3 to 8.2?

You need to troll through the CVS archives to find that patch and try to
apply it to 8.2. This feature will not be backpatched because we don't
backpatch features to previous branches.

---------------------------------------------------------------------------

>
> Regards
> Dhaval
>
> On Nov 13, 2007 11:26 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Tue, 2007-11-13 at 00:07 -0500, Greg Smith wrote:
> > > On Mon, 12 Nov 2007, Mason Hale wrote:
> > >
> > > > After the wal segment file is copied by the restore_command script, is
> > > > it safe to delete it from my archive?
> > >
> > > While I believe you can toss them immediately,
> >
> > This is almost never possible. The last WAL file that must be kept
> > should be sufficient to allow recovery to restart from the last
> > restartpoint. So a variable number of WAL files needs to be kept, not 1,
> > not 2 and certainly never 0.
> >
> > pg_standby with 8.2 provides a -k option to allow keeping last N files,
> > whereas 8.3 passes the %r parameter to show the filename of the last
> > file that must be kept.
> >
> > > you should considering
> > > keeping those around for a bit regardless as an additional layer of
> > > disaster recovery resources. I try to avoid deleting them until a new
> > > base backup is made, because if you have the last backup and all the
> > > archived segments it gives you another potential way to rebuild the
> > > database in case of a large disaster damages both the primary and the
> > > secondary. You can never have too many ways to try and recover from such
> > > a situation.
> >
> > Agreed
> >
> > --
> > Simon Riggs
> > 2ndQuadrant http://www.2ndQuadrant.com
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: In versions below 8.0, the planner will ignore your desire to
> > choose an index scan if your joining column's datatypes do not
> > match
> >
>
>
>
> --
> Dhaval Shah
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2007-11-14 18:47:10 Re: PLpgsql debugger question
Previous Message Joao Miguel Ferreira 2007-11-14 18:41:56 Re: pg_dump problem