From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Commit timestamp |
Date: | 2007-02-02 04:23:00 |
Message-ID: | 8E577E67-51DD-4944-B33E-183AA6D081A2@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2007-02-02 04:52:27 | Re: Proposal: Snapshot cloning |
Previous Message | Jim Nasby | 2007-02-02 04:04:58 | Re: Archive log compression keeping physical log available in the crash recovery |