From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Jim Nasby <decibel(at)decibel(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Commit timestamp |
Date: | 2007-02-03 20:52:50 |
Message-ID: | 45C4F622.8000906@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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 #
From | Date | Subject | |
---|---|---|---|
Next Message | Theo Schlossnagle | 2007-02-03 21:05:20 | Re: Proposal: Commit timestamp |
Previous Message | Andrew Dunstan | 2007-02-03 19:54:24 | Re: [HACKERS] \copy (query) delimiter syntax error |