Re: PITR

Hi Raghavendra,

I used standby_mode=on and it worked. I can put checkpoints (not database checkpoint :)) in between and still be in recovery state. This is what I wanted.

Thanks for your help!

Murthy

From: Raghavendra [mailto:raghavendra(dot)rao(at)enterprisedb(dot)com]
Sent: Monday, February 24, 2014 6:31 AM
To: Murthy Nunna
Cc: desmodemone; pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] PITR

On Sun, Feb 23, 2014 at 8:50 PM, Murthy Nunna <mnunna(at)fnal(dot)gov<mailto:mnunna(at)fnal(dot)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.

http://wiki.postgresql.org/wiki/Hot_Standby

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