Re: [HACKERS] Point in Time Recovery
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Point in Time Recovery |
Дата | |
Msg-id | 23306.1090256164@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Point in Time Recovery (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Point in Time Recovery
Re: [HACKERS] Point in Time Recovery Re: [HACKERS] Point in Time Recovery |
Список | pgsql-patches |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Tom Lane wrote: >> It should certainly go to /share as a .sample file. I was thinking that >> initdb should perhaps copy it into $PGDATA (still as .sample, not as >> .conf!) so it'd be right there when you need it. > I think /share is best. Okay, we agree on that part at least; I'll take care of it. If anyone wants to argue for further copying during initdb, that can be added later. > I am confused. Aren't we always doing a restore from a backup? No. This code serves two purposes: recovery from archived WAL and point-in-time recovery. You might want to do a PITR run at a time where not all your WAL segments have been pushed to archive. Indeed the latest one can never be so pushed, since it's unfinished. Suppose you are trying to do PITR recovery to a time just a few minutes ago that is still in the latest WAL segment --- there is simply not any legal way to have that come from the archive. So we can't simply zero out pg_xlog at the start of a PITR run, even if there weren't a don't-destroy-data argument against it. >> I had second thoughts about that and didn't do it in the committed >> patch, though it's certainly still open for debate. > How are we handling a crash during recovery? Retry, perhaps. It doesn't seem any different from crash-during-recovery in the non-archived scenario ... > Ah, OK, so it just keeps going. However, we don't know if what is in > pg_xlog was in the process of being copied from the archive at the time > of the crash, no? Nonissue. It goes into RECOVERYXLOG and we never assume that that's initially good. See RestoreArchivedXLog(). regards, tom lane
В списке pgsql-patches по дате отправления: