From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | richt(at)multera(dot)com |
Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PITR, checkpoint, and local relations |
Date: | 2002-08-07 15:23:02 |
Message-ID: | 16104.1028733782@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Tucker <richt(at)multera(dot)com> writes:
> But you have to prevent log files reusing while you copy data files.
>> No, I don't think so. If you are using PITR then you presumably have
>> some process responsible for archiving off log files on a continuous
>> basis. The backup process should leave that normal operational behavior
>> in place, not muck with it.
> You want the log files necessary for recovering the database to be in the
> backup copy -- don't you?
Why? As far as I can see, this entire feature only makes sense in the
context where you are continuously archiving log files to someplace
(let's say tape, for purposes of discussion). Every so often you make a
backup, and what that does is it lets you recycle the log-archive tapes
older than the start of the backup. You still need the log segments
newer than the start of the backup, and you might as well just keep the
tapes that they're going to be on anyway. Doing it the way you propose
(ie, causing a persistent change in the behavior of the log archiving
process) simply makes the whole operation more complex and more fragile,
without any actual gain in functionality that I can detect.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-07 15:29:29 | Re: Open 7.3 items |
Previous Message | Hannu Krosing | 2002-08-07 15:22:15 | Re: CLUSTER and indisclustered |