Re: patch proposal - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: patch proposal
Date
Msg-id 20160825125947.GP4028@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:
> *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...

> *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.

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.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Stas Kelvich
Date:
Subject: Re: Logical decoding restart problems
Next
From: Muhammed Roshan
Date:
Subject: Re: How to do failover in pglogical replication?