Robert Haas <robertmh...@gmail.com> writes: > ... When I say I want my handler to be > fired in 3 s, I don't mean that I want it to be fired when the system > time is 3 seconds greater than it is right now. I mean I want it to be > fired in 3 actual seconds, regardless of what dumb thing the system > clock may choose to do.
That would be lovely, certainly. But aren't you moving the goalposts rather far? I don't think we make any promises about such things today, so why has the issue suddenly gotten more pressing? In particular, why do you think Nitin's patch is proof against this? Seems to me it's probably got *more* failure cases, not fewer, if the system clock is acting funny. BTW, one could imagine addressing this concern by having timeout.c work with CLOCK_MONOTONIC instead of the regular wall clock. But I fear we'd have to drop enable_timeout_at(), for lack of ability to translate between CLOCK_MONOTONIC timestamps and those used by anybody else. Also get_timeout_start_time/get_timeout_finish_time would become problematic. Maybe we only really care about deltas, so the more restrictive API would be workable, but it seems like a nontrivial amount of work. On the whole, in these days of NTP, I'm not sure I care to spend large amounts of effort on dealing with a bogus system clock. regards, tom lane