Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group