Re: Issues Outstanding for Point In Time Recovery (PITR)

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL Hacker" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues Outstanding for Point In Time Recovery (PITR)
Date: 2002-07-05 15:39:09
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4961E10@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Let me re-write it, and I'll post it in the next version. The section
> dealt with what to do when you have a valid restored controlfile from a
> backup system, which is in the DB_SHUTDOWNED state, and that points to a
> valid shutdown/checkpoint record in the log; only the checkpoint record
> happens not to be the last one in the log. This is a situation that
> could never happen now, but would in PITR.

But it would need to be restore's responsibility to set the flag to
DB_IN_PRODUCTION, no?

> Even if we shutdown before we copy the file, we don't want a file that
> hasn't been written to in 5 weeks before it was backed up to require
> five weeks of old log files to recover. So we need to track that
> information somehow, because right now if we scanned the blocks in the
> file looking for at the page LSN's, we greatest LSN we would see might
> be much older than where it would be safe to recover from. That is the
> biggest problem, I think.

Well, if you skip a validity test it could be restore's responsibility
to know which checkpoint was last before the file backup was taken.
(When doing a backup you would need to include the last checkpoint info
== pg_control at start of backup)

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-07-05 15:50:38 Re: Proposal: CREATE CONVERSION
Previous Message Thomas Lockhart 2002-07-05 15:34:31 pg_controldata