On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
> On 2/1/2007 11:23 PM, Jim Nasby wrote:
>> On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
>>> If a per database configurable tslog_priority is given, the
>>> timestamp will be truncated to milliseconds and the increment
>>> logic is done on milliseconds. The priority is added to the
>>> timestamp. This guarantees that no two timestamps for commits
>>> will ever be exactly identical, even across different servers.
>> Wouldn't it be better to just store that information separately,
>> rather than mucking with the timestamp?
>> Though, there's anothe issue here... I don't think NTP is good
>> for any better than a few milliseconds, even on a local network.
>> How exact does the conflict resolution need to be, anyway? Would
>> it really be a problem if transaction B committed 0.1 seconds
>> after transaction A yet the cluster thought it was the other way
>> around?
>
> Since the timestamp is basically a Lamport counter which is just
> bumped be the clock as well, it doesn't need to be too precise.
Unless I'm missing something, you are _treating_ the counter as a
Lamport timestamp, when in fact it is not and thus does not provide
semantics of a Lamport timestamp. As such, any algorithms that use
lamport timestamps as a basis or assumption for the proof of their
correctness will not translate (provably) to this system.
How are your counter semantically equivalent to Lamport timestamps?
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
