Re: Why we really need timelines *now* in PITR

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Why we really need timelines *now* in PITR
Дата
Msg-id 874qo0r5l8.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Why we really need timelines *now* in PITR  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Список pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

> Also, I need to be sure that pg_dumpall is enough, and I don't need to make
> sure I issue a checkpoint before the pg_dumpall or anything.

I think if you're using PITR you don't use pg_dump you just tar up the PGDATA
directory.

Of course you can still use pg_dump to save logical exports for use in other
purposes. They're useful for loading into test databases for poking around in
the data for example.

But the transaction logs aren't going to be applicable to a database restored
from a logical pg_dump. That's effectively a completely fresh database even if
it has functionally equivalent data in it. The transaction logs are physical;
they store "replace this block with the following raw data". That can't be
applied to a logically equivalent but physically dissimilar database.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: more signals (was: Function to kill backend)
Следующее
От: Suresh Tri
Дата:
Сообщение: PostgreSQL development