From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Point in Time Recovery
Date: Tue, 13 Jul 2004 21:25:50 +0100
Message-ID: <1089750349.17493.3092.camel@stromboli> (raw)
In-Reply-To: <15780.1089728984@sss.pgh.pa.us>
References: <1089060299.17493.58.camel@stromboli>
<4263.1089064016@sss.pgh.pa.us>
<1089150005.17493.270.camel@stromboli>
<1089718702.17493.2527.camel@stromboli>
<15780.1089728984@sss.pgh.pa.us>
On Tue, 2004-07-13 at 15:29, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Please tell me that we can ignore the state of the clog,
>
> We can.
>
In general, you are of course correct.
> The reason that keeping track of timelines is interesting for xlog is
> simply to take pity on the poor DBA who needs to distinguish the various
> archived xlog files he's got laying about, and so that we can detect
> errors like supplying inconsistent sets of xlog segments during restore.
>
> This does not apply to clog because it's not archived. It's no more
> than a data file. If you think you have trouble recreating clog then
> you have the same issues recreating data files.
I'm getting carried away with the improbable....but this is the rather
strange, but possible scenario I foresee:
A sequence of times...
1. We start archiving xlogs
2. We take a checkpoint
3. we commit an important transaction
4. We take a backup
5. We take a checkpoint
As stands currently, when we restore the backup, controlfile says that
last checkpoint was at 2, so we rollforward from 2 THRU 4 and continue
on past 5 until end of logs. Normally, end of logs isn't until after
4...
When we specify a recovery target, it is possible to specify the
rollforward to complete just before point 3. So we use the backup taken
at 4 to rollforward to a point in the past (from the backups
perspective). The backup taken at 4 may now have data and clog records
written by bgwriter.
Given that time between checkpoints is likely to be longer than
previously was the case...this becomes a non-zero situation.
I was trying to solve this problem head on, but the best way is to make
sure we never allow ourselves such a muddled situation:
ISTM the way to avoid this is to insist that we always rollforward
through at least one checkpoint to guarantee that this will not occur.
...then I can forget I ever mentioned the ****** clog again.
I'm ignoring this issue for now....whether it exists or not!
Best Regards, Simon Riggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: simon@2ndquadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: Point in Time Recovery
In-Reply-To: <1089750349.17493.3092.camel@stromboli>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox