Re: Proposal: Commit timestamp

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Theo Schlossnagle <jesus(at)omniti(dot)com>
Cc: Jim Nasby <decibel(at)decibel(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Commit timestamp
Date: 2007-02-03 21:38:51
Message-ID: 45C500EB.6060805@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
> 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?

Yes, you must be missing something.

The last used timestamp is remembered. When a remote transaction is
replicated, the remembered timestamp is set to max(remembered, remote).
For a local transaction, the remembered timestamp is set to
max(remembered+1ms, systemclock) and that value is used as the
transaction commit timestamp.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2007-02-03 21:50:19 Re: Proposal: Change of pg_trigger.tg_enabled and adding
Previous Message Peter Eisentraut 2007-02-03 21:08:45 Re: --enable-debug does not work with gcc