Re: Win32, PITR, nested transactions, tablespaces

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Win32, PITR, nested transactions, tablespaces
Date: 2004-06-01 16:44:37
Message-ID: 87pt8j6xe2.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christopher Browne <cbbrowne(at)acm(dot)org> writes:

> PITR may turn out to be a "don't care" item if Slony1 winds up
> providing its own approach to PITR. (e.g. - if you write out to
> disk the sets of SQL statements that are to be applied to a replica,
> then the spooled sets of these statements represent a history of
> updates that can be used to do PITR.)

In the long run nothing can substitute for PITR. It's the only way to get a
backup that is guaranteed to restore you to exactly what you had before.

Logical dumps a la pg_dump suffer from having to unparse and parse all the
data. Any data types that don't accurately store themselves as text (such as
arrays currently, due to the index lower bound) get corrupted.

SQL level replication, a la Slony wouldn't serve if you have any
non-deterministic behaviour. And given SQL's set theoretic roots
non-deterministic behaviour can creep in in places where it's not expected,
such as any query that doesn't have an ORDER BY clause.

Both of these tools have their uses, but they don't provide a rock solid
guarantee that you can restore a machine to exactly what you had previously.
To do that you really want something that works at the storage level and
doesn't try to re-interpret data or reapply any logic.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2004-06-01 16:52:32 Re: Fast index build vs. PITR
Previous Message Bob.Henkel 2004-06-01 16:15:11 Re: Official Freeze Date for 7.5: July 1st, 2004