Christopher Browne <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
