2012/6/16 Tom Lane <tgl@sss.pgh.pa.us>:
[... cut ...]
> (1) In backend_read_statsfile, make an initial attempt to read the stats
> file and then read GetCurrentTimestamp after that. If the local clock
> reading is less than the stats file's timestamp, we know that some sort
> of clock skew or glitch has happened, so force an inquiry message to be
> sent with the local timestamp. But then accept the stats file anyway,
> since the skew might be small and harmless. The reason for the forced
> inquiry message is to cause (2) to happen at the collector.
>
> (2) In pgstat_recv_inquiry, if the received inquiry_time is older than
> last_statwrite, we should suspect a clock glitch (though it might just
> indicate delayed message receipt). In this case, do a fresh
> GetCurrentTimestamp call, and if the reading is less than
> last_statwrite, we know that the collector's time went backwards.
> To recover, reset these variables as we do at startup:
> last_statrequest = GetCurrentTimestamp();
> last_statwrite = last_statrequest - 1;
> to force an immediate write to happen with the "new" local time.
>
> (1) is basically free in terms of the amount of work done in non-broken
> cases, though it will require a few more lines of code. (2) means
> adding some GetCurrentTimestamp calls that did not occur before, but
> hopefully these will be infrequent, since in the absence of clock
> glitches they would only happen when a backend's demand for a new stats
> file is generated before the collector starts to write a new stats file
> but not received till afterwards.
>
> Comments? Anyone see a flaw in this design? Or want to argue that
> we shouldn't do anything about such cases?
What happens when Daylight saving time ends? Or it doesn't matter in
this scenario?
regards
--
Dickson S. Guedes
mail/xmpp: guedes@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br