Search Postgresql Archives

Re: PITR and warm standby setup questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



No problem.

One more question, is there a way to find out, without going through a
test install, and from release notes etc. for 8.3 if the database
needs migration from 8.2 to 8.3 or not.

Regards
Dhaval

On Nov 14, 2007 10:44 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx>        http://momjian.us
>   EnterpriseDB                             http://postgres.enterprisedb.com
>
>   + If your life is a hard drive, Christ can be your backup. +
>



-- 
Dhaval Shah

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux