Re: [HACKERS] Point in Time Recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, markw(at)osdl(dot)org, kn(at)mgnet(dot)de, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Point in Time Recovery
Date: 2004-07-19 16:56:04
Message-ID: 23306.1090256164@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Bill Chandler 2004-07-19 19:25:01 VACUUM ANALYZE and REINDEX
Previous Message Roberto De Shong 2004-07-19 16:38:59 Can't increase max connections

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2004-07-19 17:01:43 Re: pg_dump bug fixing
Previous Message Josh Berkus 2004-07-19 16:36:17 Re: pg_dump bug fixing

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-07-19 20:24:52 Re: [HACKERS] Point in Time Recovery
Previous Message Bruce Momjian 2004-07-19 16:35:05 Re: [HACKERS] Point in Time Recovery