From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Point in Time Recovery |
Date: | 2004-07-13 20:25:50 |
Message-ID: | 1089750349.17493.3092.camel@stromboli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers pgsql-patches |
On Tue, 2004-07-13 at 15:29, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-13 21:19:56 | Re: Point in Time Recovery |
Previous Message | Bill Chandler | 2004-07-13 20:01:06 | Using PL/pgSQL with statically built PostgreSQL binaries |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-07-13 20:54:01 | Re: [HACKERS] Is "trust" really a good default? |
Previous Message | Peter Eisentraut | 2004-07-13 20:21:05 | Another locale test program |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-07-13 20:54:01 | Re: [HACKERS] Is "trust" really a good default? |
Previous Message | Magnus Hagander | 2004-07-13 20:20:42 | Re: [HACKERS] Is "trust" really a good default? |