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.
-- 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