On 2/13/13 10:06 PM, Vlad Arkhipov wrote:
>> - I don't need to deal with update conflicts, because I use clock_timestamp() instead of current_timestamp.
> You can still come across a conflict even with clock_timestamp(). What if clocks go back during the time
synchronization?Even if you have absolutely precious clocks, there are may be clock skew on different CPUs, low system
clocktime resolution, etc.
Sorry for the late reply, catching up on email...
If you want to track the history of something, "measured time" is absolutely NOT the way to do it. I use the term
"measuredtime" to differentiate from the real-world concept of time that is forever flowing forward from one instant to
thenext. The problem with measured time is that it's incredibly easy to screw up. Clocks out of sync, clocks running
backwards,etc. Heck, it's not even clear what time you should actually use: transaction start, wallclock, or
transactionend.
For any kind of history tracking to actually be robust you have no choice but to link one history record to another so
thatyou can actually walk down a chain. Of course you might want to capture a timestamp as part of your history
metadata,but you better be ready to deal with a history record with a timestamp that is *earlier* than the prior
historyrecord.
BTW, we've been working on a generic history implementation at work; hopefully we'll be able to release it relatively
soon.