Bruce Momjian <[EMAIL PROTECTED]> 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.
What is *very* likely, but has no chance of being supported by PITR,
is that he wishes he could keep the results of transactions committed
shortly after the error he's trying to undo. At the microsecond level,
the transaction commit order is not that predictable anyway (except of
course when one transaction's lock blocks another). I think it's
pointless to get all exercised about whether you can stop on *this*
transaction and not *that* one when they are committing so close
together. Half the time the user will be wishing he could omit the
first and include the second, but he doesn't get to do that, and so
I say being able to point to the stopping xact by xid is just an
exercise in technical hair-splitting. I don't think it solves any
real-world problem.
Another way of putting this is that one-second resolution in the states
you have available to restore to is plenty good enough for real-world
cases.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
