| 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: | Whole Thread | Raw Message | 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 |