Re: PITR - Mailing list pgsql-admin

From Raghavendra
Subject Re: PITR
Date
Msg-id CA+h6AhhXKf=EYjYgnOFeVQ06R5FcdJ=E3tpq7Y0RTXLGjB8HNQ@mail.gmail.com
Whole thread Raw
In response to Re: PITR  (Murthy Nunna <mnunna@fnal.gov>)
Responses Re: PITR  (Murthy Nunna <mnunna@fnal.gov>)
List pgsql-admin
On Sun, Feb 23, 2014 at 8:50 PM, Murthy Nunna <mnunna@fnal.gov> wrote:

Raghavendra,

 

Thanks for testing and confirming the behavior of “pause” setting.

 

While I understand your explanation, I feel I am still missing something. IMHO, when I say pause using “pause” setting, no matter what, I expect the recovery to wait for manual intervention.


I very much agree with your point that it has to pause when you ask for it, however, as per design (some other might comment on this well) am guessing it will open the database if no wals are there though you intentionally hide them. 

You can use (HOT STANDBY) standby_mode=on which does the same thing, it just waits for the WAL files but it won't open the database until you pass the trigger file. In hot standby, it apply the existing wals fed and wait for coming wals and it won't come out of recovery.  This you can try with below link.

 

I myself can come up with number of reasons for doing so… e.g I may be purposely “hiding” some WALs somewhere else, or maybe I have several thousands of WALs that I want to parallelize the process of applying some logs while I recall some from tapes.

 

Let me know what you think.


Agreed it might be possible of not having wals at the moment and waiting for them to copy, however, I prefer in that case to use hot_standby. Pause just works in case if it sees some pending file in Arch.. location.

My explanation might not reach to your expectation, but I am sure few other's here might share their inputs.
--Raghav

pgsql-admin by date:

Previous
From: bricklen
Date:
Subject: Re: PITR
Next
From: Murthy Nunna
Date:
Subject: Re: PITR