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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
