Bug#534978: clock drift in Xen domU with clocksource=xen
On Thu, Feb 25, 2010 at 02:27:55PM +0100, Josip Rodin wrote:
> > No. The time resolution is not defined and within one step it will
> > always provide the same value.
> What? :) The problem here is that a time readout function provides the same
> value across *two* steps. A monotonic function is one which allows for that.
> A strictly increasing function is one which does not. Most of the time,
> just monotonic is okay, but not always.
No, the time is only monotone, not strictly monotone. (With discreet
values, it is not possible to make it strictly monotone.)
> > > and it also caused occasional PostgreSQL errors
> > > with tables that had timestamp columns as keys, since it became possible
> > > for two independent transactions to come in at the exact same time.
> > Äh, where is documented, that this supposed to work anyway?
> The key column has a unique constraint and a default value of current
> timestamp. Even if two perfectly concurrent writers come in to add a new
> record, it's still logical to expect for them to be serialized to a minimal
> extent, because the database itself is explicitly instructed to input all
> values and maintain their uniqueness. The expectation that all updates take
> at least one minimal unit of time is perhaps not theoretically valid, but
> it's certainly like that in the real world (every action takes *some*
> perceivable time).
Wrong answer. Where is this documented as working in the postgresql
documentation?
Bastian
--
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8
Reply to: