]> granicus.if.org Git - postgresql/commit
Fix stats collector to recover nicely when system clock goes backwards.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 17 Jun 2012 21:11:07 +0000 (17:11 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 17 Jun 2012 21:11:49 +0000 (17:11 -0400)
commit9e18eacbdff2ae2abd5ff38eee725e6399e39b41
tree25160ab82ae7779d42328c2f20cf1291c4ca5f7b
parent920febdad5073688fac34664249ab329dced8320
Fix stats collector to recover nicely when system clock goes backwards.

Formerly, if the system clock went backwards, the stats collector would
fail to update the stats file any more until the clock reading again
exceeds whatever timestamp was last written into the stats file.  Such
glitches in the clock's behavior are not terribly unlikely on machines
not using NTP.  Such a scenario has been observed to cause regression test
failures in the buildfarm, and it could have bad effects on the behavior
of autovacuum, so it seems prudent to install some defenses.

We could directly detect the clock going backwards by adding
GetCurrentTimestamp calls in the stats collector's main loop, but that
would hurt performance on platforms where GetCurrentTimestamp is expensive.
To minimize the performance hit in normal cases, adopt a more complicated
scheme wherein backends check for clock skew when reading the stats file,
and if they see it, signal the stats collector by sending an extra stats
inquiry message.  The stats collector does an extra GetCurrentTimestamp
only when it receives an inquiry with an apparently out-of-order
timestamp.

To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages
to carry the backend's current clock reading as well as its stats cutoff
time.  The latter, being intentionally slightly in-the-past, would trigger
more clock rechecks than we need if it were used for this purpose.

We might want to backpatch this change at some point, but let's let it
shake out in the buildfarm for awhile first.
src/backend/postmaster/pgstat.c
src/include/pgstat.h