At 11:44 PM 10/17/2011, Tom Lane wrote:
Alban Hertroys <haramrae@xxxxxxxxx> writes:
> On 17 October 2011 17:25, Steve Crawford
<scrawford@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Even stand-alone statements take place within a transaction - just not an
>> explicit one.
> I doubt that more than 2.368 ms passed between the start of a
> transaction and the stand-alone statement it's wrapping though. Not
> impossible, but clock skew seems more likely to me.
We take some pains to ensure that the same gettimeofday reading is used
for both a transaction's start timestamp and the statement timestamp of
its first statement. So I'm not sure what's up with Scott's report.
But in the OP's EXPLAIN case, that's the difference between successive
readings taken within the EXPLAIN code, so it's hard to see how to
explain it in any other way than "your system clock went backwards".
Possibly the underlying cause is clock skew between different processors
on a multiprocessor machine?
Some years ago the early Athlon Athlon X2 CPUs had unsynced TSCs and
the OSes used the TSCs to speed up gettimeofday (somehow despite all
the advances in CPUs, chipsets etc, billions of transistors the
hardware bunch didn't help much for time keeping, yes there's HPET on
some motherboards but HPET isn't that great either AFAIK ).
I suppose this might be due to a different but still similar issue.
References:
<http://developer.amd.com/Membership/Print.aspx?ArticleID=38&web=http%3A%2F%2Fdeveloper.amd.com>http://developer.amd.com/Membership/Print.aspx?ArticleID=38&web=http%3A%2F%2Fdeveloper.amd.com
http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
Regards,
Link.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
