From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com> |
Cc: | Richard Tucker <richt(at)multera(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PITR, checkpoint, and local relations |
Date: | 2002-08-09 03:59:00 |
Message-ID: | 27852.1028865540@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"J. R. Nield" <jrnield(at)usol(dot)com> writes:
>> Uh, why? Why not just force a checkpoint and remember the exact
>> location of the checkpoint within the current log file?
> If I do a backup with PITR and save it to tape, I need to be able to
> restore it even if my machine is destroyed in a fire, and all the logs
> since the end of a backup are destroyed.
And for your next trick, restore it even if the backup tape itself is
destroyed. C'mon, be a little reasonable here. The backups and the
log archive tapes are *both* critical data in any realistic view of
the world.
> Is the complexity really that big of a problem with this?
Yes, it is. Didn't you just admit to struggling with bugs introduced
by exactly this complexity?? I don't care *how* spiffy the backup
scheme is, if when push comes to shove my backup doesn't restore because
there was a software bug in the backup scheme. In this context there
simply is not any virtue greater than "simple and reliable".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2002-08-09 05:07:17 | Re: [HACKERS] Linux Largefile Support In Postgresql RPMS |
Previous Message | Tom Lane | 2002-08-09 03:52:36 | Re: CLUSTER and indisclustered |