Re: Add shutdown_at_recovery_target option to recovery.conf - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Add shutdown_at_recovery_target option to recovery.conf
Date
Msg-id 5453A851.6030400@2ndquadrant.com
Whole thread Raw
In response to Re: Add shutdown_at_recovery_target option to recovery.conf  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Add shutdown_at_recovery_target option to recovery.conf
List pgsql-hackers
Hi,

Attached is the v2 of the patch with the review comments addressed (see
below).

On 29/10/14 21:08, Petr Jelinek wrote:
> On 29/10/14 20:27, Asif Naeem wrote:
>> 1. It seems that following log message need to be more descriptive about
>> reason for shutdown i.e.
>>
>>     +                   if (recoveryShutdownAtTarget && reachedStopPoint)
>>     +                       {
>>     +                               ereport(LOG, (errmsg("shutting
>> down")));
>>
>
> Agreed, I just wasn't sure on what exactly to writes, I originally had
> there "shutting down by user request" or some such but that's misleading.
>

I changed it to "shutting down at recovery target" hope that's better.

>> 2. As Simon suggesting following recovery settings are not clear i.e.
>>
>>     shutdown_at_recovery_target = true
>>     pause_at_recovery_target = true
>
> Hmm I completely missed Simon's email, strange. Well other option would
> be to throw error if both are set to true - error will have to happen
> anyway if action_at_recovery_target is set to shutdown while
> pause_at_recovery_target is true (I think we need to keep
> pause_at_recovery_target for compatibility).
>
> But considering all of you think something like
> action_at_recovery_target is better solution, I will do it that way then.

Done, there is now action_at_recovery_target which can be set to either
pause, continue or shutdown, defaulting to pause (which is same as old
behavior of pause_at_recovery_target defaulting to true).
I also added check that prohibits using both pause_at_recovery_target
and action_at_recovery_target in the same config, mainly to avoid users
shooting themselves in the foot.

>
>>
>> 3. As it don’t rename reconvery.conf, subsequent attempt (without any
>> changes in reconvery.conf) to start of server keep showing the following
>> i.e.
>>
>>     ...
>>     LOG:  redo starts at 0/1803620
>>     DEBUG:  checkpointer updated shared memory configuration values
>>     LOG:  consistent recovery state reached at 0/1803658
>>     LOG:  restored log file "000000010000000000000002" from archive
>>     DEBUG:  got WAL segment from archive
>>     LOG:  restored log file "000000010000000000000003" from archive
>>     DEBUG:  got WAL segment from archive
>>     LOG:  restored log file "000000010000000000000004" from archive
>>     DEBUG:  got WAL segment from archive
>>     LOG:  restored log file "000000010000000000000005" from archive
>>     DEBUG:  got WAL segment from archive
>>     LOG:  restored log file "000000010000000000000006" from archive
>>     DEBUG:  got WAL segment from archive
>>     …
>>
>
> Yes, it will still replay everything since last checkpoint, that's by
> design since otherwise we would have to write checkpoint on shutdown and
> that would mean the instance can't be used as hot standby anymore and I
> consider that an important feature to have.
>

I added note to the documentation that says this will happen.

--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing Catalog Locking
Next
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps