Re: XLog: how to log?

On Wed, 2004-05-12 at 04:47, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Tom Lane wrote:
> > >> I think this argument is largely a red herring ... but if it makes you
> > >> feel better, we could change the contents of the commit timestamp to
> > >> be gettimeofday() output (seconds+microseconds) instead of just time()
> > >> output. That should be precise enough for practical purposes.
> >
> > > I am saying timestamp as used for specifying a recovery location might
> > > not be unique enough, no?
> >
> > Why not? I don't think there are going to be practical situations where
> > the user knows that he wants transactions up till exactly 6:48:52 PM
> > anyway. He'll be lucky if he knows that the junior DBA dropped the
> > wrong table around 6:30 :-(. It's even less likely that he desperately
> > needs to revert to before such a disaster but still get in a transaction
> > that happened to commit at the same second. Take it down to the
> > microsecond level and the use-case becomes vanishingly small.
>
> Here is my logic. Once they have a way to dump the WAL contents, folks
> trying to recover to a specific point in the past are going to look at
> the WAL dump and hopefully identify the transaction that was bad. They
> then will want to roll back to just before that transaction.
>
> Do they subtract one second from the transaction? Seems it would be
> easier to just pick the xid that was just before the bad one. Also,
> considering the various time formats and timezone issues that it is
> simpler to just have them specify an xid.

Well, I think I agree with both sides of this debate.

Solution: provide both timestamp AND Xid capability. We assume that if
they specify Xid, it is because they know and, for whatever reason,
care, about the exact specification of where recovery stops.

If you know a large statement just executed in error, then you want to
restore back to just before the error.

My earlier angst was based upon mistaking that there was no timestamp.
There is now a simple choice of recovery targets and fairly simple to
implement both. Design is now clear for me.

Best Regards, Simon Riggs