On Thu, Aug 18, 2016 at 7:20 PM, Stephen Frost <sfrost@snowman.net> wrote:
* 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.
I understand that, in warm-standby, PG does continuously replay WAL without bringing up the database as the database will be in standby mode, which sounds ideal.
While recovering the database to a particular recovery target point ( and there is no requirement to setup standby ), then, there is a risk that database will get promoted due to missing or corrupt WALs. Which means, there is no way to avoid promotion and resume WAL recovery. An option like "pause" with a new parameter would be ideal to prevent database promotion at a default recovery target, which is "immediate" or "end-of-WAL".
