Re: Execution-time-sensitive timestamp regression tests

Tom Lane wrote:
> Both of the observed failures are on Windows machines, where I'm told
> that the resolution of gettimeofday() is an abysmal 55msec, so it
> seems that the only surprise here is that we haven't seen the failure
> often before.

Actually, reading up some more it seems the 55msec was for win98
systems. Modern systems usually have around 10ms.

And I agree that it's strange we haven't seen it before. Could it be a
side-effect from something that happened lately, or should we consider
it purely random?


> It might be worth trying to improve the resolution of now() on
> Windows, though I didn't much care for the ideas Magnus had about how
> to do that when I asked him earlier today.

For the record, what we were talking about was snapshotting the time at
backend start and then use QueryPerformanceCounter() to see what
happened and do some calculation.

The other option appears to be to use a multimedia timer,
timeGetSystemTime(). But the comment for that one still says "The
default precision of the timeGetTime function can be five milliseconds
or more, depending on the machine. You can use the timeBeginPeriod and
timeEndPeriod functions to increase the precision of timeGetTime. If
you do so, the minimum difference between successive values returned by
timeGetTime can be as large as the minimum period value set using
timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and
QueryPerformanceFrequency functions to measure short time intervals at
a high resolution, "


So the bottom line is - if you want to have high performance timing,
you really should use QueryPerformance...().

//Magnus