Re: patch proposal - Mailing list pgsql-hackers

From Venkata B Nagothi
Subject Re: patch proposal
Date
Msg-id CAEyp7J8q+JHD_U+XR07_MwW6uQpWuEZ2J6SVN+wba-ANyrDM-A@mail.gmail.com
Whole thread Raw
In response to Re: patch proposal  (Stephen Frost <sfrost@snowman.net>)
Responses Re: patch proposal  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

On Thu, Aug 25, 2016 at 10:59 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Venkata B Nagothi (nag1010@gmail.com) wrote:
> *Query 1*
>
> What about the existing parameter called "recovery_target" which accepts
> only one value "immediate", which will be similar to the "promote" option
> with the to-be-introduced new parameter.
> Since this parameter's behaviour will be incorporated into the new
> parameter, I think, this parameter can be deprecated from the next
> PostgreSQL version ?

I don't think we can really consider that without having a good answer
for what the "new parameter" is, in particular...

Sure. I Agree.
 
> *Query 2*
>
> I am thinking that the new parameter name should be
> "recovery_target_incomplete" or "recovery_target_incomplete_action" which
> (by name) suggests that recovery target point is not yet reached and
> accepts options "pause","promote" and "shutdown".
>
> The other alternative name i thought of was -
> "recovery_target_immediate_action", which (by name) suggests the action to
> be taken when the recovery does not reach the actual set recovery target
> and reaches immediate consistent point.

I don't really care for any of those names.  Note that "immediate" and
"the point at which we realize that we didn't find the recovery target"
are *not* necessairly the same.  Whatever we do here needs to also cover
the 'recovery_target_name' option, where we're only going to realize
that we didn't find the restore point when we reach the end of the WAL
stream.

Yes, all the recovery targets (including recovery_target_name) will be taken into consideration. 
The whole idea about this patch is to ensure PG realises that the recovery is incomplete if the specified recovery target point is not found at the end of the WAL stream.
 
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.

"pause"

This option ensures database recovery pauses if any of the specified recovery target ("XID", "Name" or "time") is not reached. So that WAL replay can be resumed if required.

"shutdown"

This option ensures database shuts down if any of the mentioned recovery target points (XID, Name or time) is not reached.

Regards,
Venkata B N

Fujitsu Australia




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: increasing the default WAL segment size
Next
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive