| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Theo Schlossnagle" <jesus(at)omniti(dot)com> |
| Cc: | "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Jim Nasby" <decibel(at)decibel(dot)org> |
| Subject: | Re: Proposal: Commit timestamp |
| Date: | 2007-02-04 16:34:00 |
| Message-ID: | 87y7nd287b.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Theo Schlossnagle" <jesus(at)omniti(dot)com> writes:
> As the clock must be incremented clusterwide, the need for it to be insync with
> the system clock (on any or all of the systems) is obviated. In fact, as you
> can't guarantee the synchronicity means that it can be confusing -- one
> expects a time-based clock to be accurate to the time. A counter-based clock
> has no such expectations.
So if the nodes get split they can keep operating independently but clients
can see that there's no guarantee of ordering against transactions from other
nodes because the clock isn't advancing?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2007-02-04 17:36:16 | Re: VC2005 build and pthreads |
| Previous Message | Theo Schlossnagle | 2007-02-04 15:53:32 | Re: Proposal: Commit timestamp |