Re: PITR and warm standby setup questions - Mailing list pgsql-general

From Bruce Momjian
Subject Re: PITR and warm standby setup questions
Date
Msg-id 200711141844.lAEIi9X19821@momjian.us
Whole thread Raw
In response to Re: PITR and warm standby setup questions  ("Dhaval Shah" <dhaval.shah.m@gmail.com>)
Responses Re: PITR and warm standby setup questions  ("Dhaval Shah" <dhaval.shah.m@gmail.com>)
List 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@2ndquadrant.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

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

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: PLpgsql debugger question
Next
From: "Joshua D. Drake"
Date:
Subject: Re: PLpgsql debugger question