| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
| Cc: | richt(at)multera(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-03 00:44:27 |
| Message-ID: | 29442.1028335467@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
>> 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.
> Well, PITR without log archiving could be alternative to
> pg_dump/pg_restore, but I agreed that it's not the big
> feature to worry about.
Seems like a pointless "feature" to me. A pg_dump dump serves just
as well to capture a snapshot --- in fact better, since it's likely
smaller, definitely more portable, amenable to selective restore, etc.
I think we should design the PITR dump to do a good job for PITR,
not a poor job of both PITR and pg_dump.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-08-03 00:50:34 | Re: PITR, checkpoint, and local relations |
| Previous Message | Tom Lane | 2002-08-03 00:41:06 | Planned simplification of catalog index updates |