Re: Why we really need timelines *now* in PITR - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Why we really need timelines *now* in PITR
Date
Msg-id 874qo0r5l8.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Why we really need timelines *now* in PITR  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List 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 by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: more signals (was: Function to kill backend)
Next
From: Suresh Tri
Date:
Subject: PostgreSQL development