On Wed, 2004-05-12 at 04:47, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 22 of 23 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 10, '04 at 11:13p
activeMay 12, '04 at 9:20a



site design / logo © 2021 Grokbase