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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
