Re: Standby accepts recovery_target_timeline setting? - Mailing list pgsql-hackers

From David Steele
Subject Re: Standby accepts recovery_target_timeline setting?
Date
Msg-id 50e54b98-87f7-c0d6-52d6-cce67ec7dbb0@pgmasters.net
Whole thread Raw
In response to Re: Standby accepts recovery_target_timeline setting?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Standby accepts recovery_target_timeline setting?
Re: Standby accepts recovery_target_timeline setting?
List pgsql-hackers
Hi Peter,

On 9/27/19 10:36 AM, Peter Eisentraut wrote:
> On 2019-09-26 23:02, David Steele wrote:
>> On 9/26/19 4:48 PM, Peter Eisentraut wrote:
>>
>>> I don't know if recovery_target_timeline is actually useful to change in
>>> standby mode.
> 
> OK, I have committed your original documentation patch.

Thanks, that's a good start.

As Fujii noticed and I have demonstrated upthread, just about any target
setting can be used in a standby restore.  This matches the behavior of
prior versions so it's not exactly a regression, but the old docs made
no claim that standby_mode disabled targeted restore.

If fact, for both PG12 and before, setting a recovery target in standby
mode causes the cluster to drop out of standby mode.

Also, the presence or absence of recovery.signal does not seem to have
any effect on how targeted recovery proceeds, except as Fujii has
demonstrated in [1].

I'm not sure what the best thing to do is.  The docs are certainly
incorrect, but fixing them would be weird.  What do we say, setting
targets will exit standby mode?  That certainly what happens, though.

Also, the fact that target settings are being used when recovery.signal
is missing is contrary to the docs, and this is a new behavior in PG12.
 Prior to 12 you could not have target settings without recovery.conf
being present by definition.

I think, at the very least, the fact that targeted recovery proceeds in
the absence of recovery.signal represents a bug.

-- 
-David
david@pgmasters.net

[1]
https://www.postgresql.org/message-id/CAHGQGwEYYg_Ng%2B03FtZczacCpYgJ2Pn%3DB_wPtWF%2BFFLYDgpa1g%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Improving on MAX_CONVERSION_GROWTH
Next
From: Andres Freund
Date:
Subject: Re: Improving on MAX_CONVERSION_GROWTH