On Thu, Feb 25, 2010 at 01:33:05PM +0100, Bastian Blank wrote:
> On Thu, Feb 25, 2010 at 12:18:54PM +0100, Josip Rodin wrote:
> > Using jiffies as a clock source is not a "solution", it's a workaround,
> > because its resolution (CONFIG_HZ^1) is not good enough for reading
> > microseconds, that is, time with microseconds will become just monotonic.
> > This will cause problems for any program that wants its time readouts to
> > be strictly increasing, as real-world time usually is :)
>
> 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.
> > 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).
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100225132755.ga11...@orion.carnet.hr
