On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost <sfr...@snowman.net> wrote:

> * Venkata B Nagothi (nag1...@gmail.com) wrote:
> > On Thu, Aug 25, 2016 at 10:59 PM, Stephen Frost <sfr...@snowman.net>
> wrote:
> > > I'm not a fan of the "recovery_target" option, particularly as it's
> only
> > > got one value even though it can mean two things (either "immediate" or
> > > "not set"), but we need a complete solution before we can consider
> > > deprecating it.  Further, we could consider making it an alias for
> > > whatever better name we come up with.
> >
> > The new parameter will accept options : "pause", "shutdown" and "promote"
> >
> > *"promote"*
> >
> > This option will ensure database starts up once the "immediate"
> consistent
> > recovery point is reached even if it is well before the mentioned
> recovery
> > target point (XID, Name or time).
> > This behaviour will be similar to that of recovery_target="immediate" and
> > can be aliased.
> I don't believe we're really going at this the right way.  Clearly,
> there will be cases where we'd like promotion at the end of the WAL
> stream (as we currently have) even if the recovery point is not found,
> but if the new option's "promote" is the same as "immediate" then we
> don't have that.

My apologies for the confusion. Correction - I meant, "promote" option
would promote the database once the consistent point is reached at the

> We need to break this down into all the different possible combinations
> and then come up with names for the options to define them.  I don't
> believe a single option is going to be able to cover all of the cases.
> The cases which I'm considering are:
> recovery target is immediate (as soon as we have consistency)
> recovery target is a set point (name, xid, time, whatever)
> action to take if recovery target is found
> action to take if recovery target is not found
> Generally, "action" is one of "promote", "pause", or "shutdown".
> Clearly, not all actions are valid for all recovery target cases- in
> particular, "immediate" with "recovery target not found" can not support
> the "promote" or "pause" options.  Otherwise, we can support:

I Agree. This is a valid point to consider. I might have few questions over
this at a later stage.

Recovery Target  |  Found  |  Action
> -----------------|---------|----------
> immediate        |  Yes    | promote
> immediate        |  Yes    | pause
> immediate        |  Yes    | shutdown
> immediate        |  No     | shutdown
> name/xid/time    |  Yes    | promote
> name/xid/time    |  Yes    | pause
> name/xid/time    |  Yes    | shutdown
> name/xid/time    |  No     | promote
> name/xid/time    |  No     | pause
> name/xid/time    |  No     | shutdown
> We could clearly support this with these options:

> recovery_target = immediate, other
recovery_action_target_found = promote, pause, shutdown

This is currently supported by the existing parameter called

> recovery_action_target_not_found = promote, pause, shutdown

This is exactly what newly proposed parameter will do.

> One question to ask is if we need to support an option for xid and time
> related to when we realize that we won't find the recovery target.  If
> consistency is reached at a time which is later than the recovery target
> for time, what then?  Do we go through the rest of the WAL and perform
> the "not found" action at the end of the WAL stream?  If we use that
> approach, then at least all of the recovery target types are handled the
> same, but I can definitely see cases where an administrator might prefer
> an "error" option.

Currently, this situation is handled by recovery_target_inclusive
parameter. Administrator can choose to stop the recovery at any consistent
point before or after the specified recovery target. Is this what you were
referring to ?
I might need a bit of clarification here, the parameter i am proposing
would be effective only if the specified recovery target is not reached and
may not be effective if the recovery goes beyond recovery target point.

Venkata B N

Fujitsu Australia

Reply via email to