Simon Riggs wrote:
> During recovery, we would search for a timestamp. If found exactly,
> stop. If exceeded, stop. Any transactions not committed at that point
> are, as we say, out of luck. ....This approach has a certainty about it
> that I think is much better than the error prone Xid hunting approach,
> and is also more attuned to the human reality (time matters, Xids
> don't).
>
> Earlier, Bruce and I had discussed that for reasons of time pressure,
> the PITR code for this release would consist of
> a) recovery to a particular Xid
> b) later, a utility that allowed xlogs to be inspected to allow DBA to
> decide which is the correct Xid to recover to.
> Those ideas don't sound as good now....
>
> Therefore: action on me? - add a timestamp to EACH xlog record -
> something I had been shying away from.
Many transactions are going to have the same timestamp because that just
isn't precise enough to choose a particular transaction. I agree
finding a particular xid in the logs is hard. We could just scan the
logs to see if we find the xid before doing the recovery.
Anyway, I though we agreed to just get total recovery working for 7.5
and we can deal with recovery to a particular point later. Or we can
just add timestamps to the wal file header and restore to a particular
wal file date timestamp.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
