Re: PITR

Поиск
Список
Период
Сортировка
От Raghavendra
Тема Re: PITR
Дата
Msg-id CA+h6AhhXKf=EYjYgnOFeVQ06R5FcdJ=E3tpq7Y0RTXLGjB8HNQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PITR  (Murthy Nunna <mnunna@fnal.gov>)
Ответы Re: PITR  (Murthy Nunna <mnunna@fnal.gov>)
Список 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 по дате отправления:

Предыдущее
От: bricklen
Дата:
Сообщение: Re: PITR
Следующее
От: Murthy Nunna
Дата:
Сообщение: Re: PITR