Re: PITR, checkpoint, and local relations

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

In response to

Browse pgsql-hackers by date

  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