| 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-08 03:41:17 |
| Message-ID: | 29281.1028778077@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:
> The xlog code must allow us to force an advance to the next log file,
> and truncate the archived file when it's copied so as not to waste
> space.
Uh, why? Why not just force a checkpoint and remember the exact
location of the checkpoint within the current log file?
When and if you roll back to a prior checkpoint, you'd want to start the
system running forward with a new xlog file, I think (compare what
pg_resetxlog does). But it doesn't follow that you MUST force an xlog
file boundary simply because you're taking a backup.
> This complicates both the recovery logic and XLogInsert, and I'm trying
> to kill the "last" latent bug in that feature now.
Indeed. How about keeping it simple, instead?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Copeland | 2002-08-08 03:50:03 | Another python patch -- minor |
| Previous Message | Greg Copeland | 2002-08-08 03:35:50 | Re: python patch |