Re: [HACKERS] Point in Time Recovery
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Point in Time Recovery |
Дата | |
Msg-id | 8063.1090206181@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Point in Time Recovery (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Point in Time Recovery
Re: [HACKERS] Point in Time Recovery Re: [HACKERS] Point in Time Recovery |
Список | pgsql-patches |
Simon Riggs <simon@2ndquadrant.com> writes: > Latest version, pitr_v5_2.patch... Reviewed and committed with some adjustments. I see the following significant loose ends: * Documentation is, um, lacking. (One point in particular is that I inserted the recovery.conf.sample file into CVS, but did not fill in the patch's lack of attempt to install it anywhere.) * As Bruce has pointed out already, the process of making a backup needs some improvements for more safety: the starting and ending WAL offsets have got to be recorded somehow. * As I have pointed out already, we need to invent "timelines" to allow incompatible WAL segments to exist side-by-side. I will volunteer to look into this. * I think creating a .ready file during XLogFileOpen is completely bogus, for reasons mentioned in committed comments (look for XXX). Possibly this can go away with timelines. * I am wondering if it wouldn't be a good idea to remove the local copy of any segment we successfully obtain from archive. The existing comments note that we might get a wrong or corrupted file from archive, but aren't we in at least as much risk of using an obsolete segment restored from backup if we leave the local segment in place? (The archive recovery run itself will know not to do this, but if we crash shortly thereafter, the ensuing recovery run would NOT know not to trust such files.) Perhaps the last point is really a backup-process issue. AFAICS there is no good reason for a backup tarfile to include $PGDATA/pg_xlog at all, and some good reasons for it not to. Can we redesign either the backup process or the disk layout so that that will not happen? Then we could stop worrying about stale local pg_xlog files. regards, tom lane
В списке pgsql-patches по дате отправления: