On 1/26/2007 9:38 AM, Stephen Frost wrote:
* Jan Wieck ([EMAIL PROTECTED]) wrote:
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
>I would be *very* concerned that system time is not a guaranteed
>monotonic entity. Surely a counter or other internally managed mechanism
>would be a better solution.
Such a counter has only "local" relevance. How do you plan to compare
the two separate counters on different machines to tell which
transaction happened last?
I'd also suggest you look into Lamport timestamps... Trusting the
system clock just isn't practical, even with NTP. I've developed
(albeit relatively small) systems using Lamport timestamps and would be
happy to talk about it offlist. I've probably got some code I could
share as well.
I think the system I described is a slightly modified Lamport generator.
The maximum timestamp of any row updated in this transaction, you can
consider that the "counters received from other nodes". Then I make sure
that the next counter (timestamp) is higher than anything I know so far,
and I add cluster-wide unique tie breaker to that.
Looking closer, I don't even have to check the timestamps of the rows
updated. Since a remote transaction replicated will bump the local
Lamport clock on commit, a local transaction modifying such a row will
have a timestamp in the future of that remote transaction, even if my
local clock is limping behind.
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 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
