Re: How should pg_standby get over the gap of timeline?
От | Fujii Masao |
---|---|
Тема | Re: How should pg_standby get over the gap of timeline? |
Дата | |
Msg-id | 3f0b79eb0811211039t578f4499t375091e63972376a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How should pg_standby get over the gap of timeline? (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: How should pg_standby get over the gap of timeline?
|
Список | pgsql-hackers |
Hi, Simon. Thanks for the comment!! On Sat, Nov 22, 2008 at 2:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Thu, 2008-11-20 at 22:41 +0900, Fujii Masao wrote: > >> In the current Synch Rep patch, the standby cannot catch up with the >> primary which has a bigger timeline. So, whenever making the standby >> catch up, a fresh base backup is required. This is obviously undesirable, >> and I'd like to get rid of this restriction. >> >> Postgres itself can recover up to a bigger timeline without a base >> backup. The remaining problem is that pg_standby cannot get over the >> gap of timeline. It continues waiting for the XLOG file with out-of-date >> timeline, and redo doesn't progress. > > We've discussed this before. My answer is the same: you are assuming it > is safe to re-enter recovery, which is not correct (currently). I'm afraid you might be right. But I cannot understand yet why it's not safe to re-enter recovery. Is it safe to re-enter recovery from the restart point after PITR stopped halfway? If it's safe, ISTM that PITR without a base backup also is safe. Please let me know what might violate a re-entry of recovery. What is your worry? > You are > also assuming that taking a base backup is an expensive operation - it > need not be so if you simply move only the files/data that have changed, > e.g. rsync. It depends on DB size and type. I think that it's important that the user *can* choose the better method according to his situation. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: