Skip site navigation (1) Skip section navigation (2)

Re: Proposal: Commit timestamp

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 (view raw or flat)
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)



In response to

Responses

pgsql-hackers by date

Next:From: Jim NasbyDate: 2007-02-02 04:52:27
Subject: Re: Proposal: Snapshot cloning
Previous:From: Jim NasbyDate: 2007-02-02 04:04:58
Subject: Re: Archive log compression keeping physical log available in the crash recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group