Re: patch proposal - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: patch proposal
Date
Msg-id 20160818092051.GL4028@tamriel.snowman.net
Whole thread Raw
In response to Re: patch proposal  (Venkata B Nagothi <nag1010@gmail.com>)
Responses Re: patch proposal  (Venkata B Nagothi <nag1010@gmail.com>)
List pgsql-hackers
* Venkata B Nagothi (nag1010@gmail.com) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Venkata B Nagothi (nag1010@gmail.com) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensure following happens if the recovery target is not reached -
> > >
> > >  a) PG pauses the recovery at the end of the WAL
> > >  b) Generates a warning in the log file saying that recovery target point
> > > is not reached (there is a patch being worked upon on by Thom on this)
> > >  c) Does not open-up the database exiting from the recovery process by
> > > giving room to resume the replay of WALs
> >
> > One thing to consider is just how different this is from simply bringing
> > PG up as a warm standby instead, with the warning added to indicate if
> > the recovery point wasn't reached.
>
> I am referring to a specific scenario (performing point-in time recovery)
> where-in a DBA attempts to bring up a standalone PG instance by restoring
> the backup and performing recovery to a particular recover target (XID,
> time or a named restore point) in the past by replaying all the available
> WAL archives, which is not quite possible through a warm-standby setup.
>
> Warm standby is more of a high-availability solution and i do not think so,
> it addresses PITR kind of situation.

No, a warm standby is one which just plays through the WAL but doesn't
bring the database up or start its own set of WAL, which is what you're
asking about.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Fix comment in ATExecValidateConstraint
Next
From: Craig Ringer
Date:
Subject: Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid