Re: Proposal: Commit timestamp
От | Jan Wieck |
---|---|
Тема | Re: Proposal: Commit timestamp |
Дата | |
Msg-id | 45C4F622.8000906@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Proposal: Commit timestamp (Jim Nasby <decibel@decibel.org>) |
Ответы |
Re: Proposal: Commit timestamp
|
Список | 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@Yahoo.com #
В списке pgsql-hackers по дате отправления: