On Wed, 13 Jun 2007, Johannes Konert wrote:
> If someone corrects the servers computer-time/date to a date before current
> time (e.g. set the clock two hours back), then the newer WAL files will have
> an older timestamp and will be deleted by accident.
This should never happen; no one should ever touch the clock by hand on a
production system. The primary and backup server should both be
syncronized via NTP. If you're thinking about clock changes for daylight
savings time, those shouldn't have any effect on timestamps, which should
be stored in UTC. If you're on Windows, I recommend reading
http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1241193,00.html and
http://www.wilsonmar.com/1clocks.htm if you're not familiar with how
UTC/NTP insulate you from this issue. On many types of systems that
process time-sensitive data, an administrator adjusting the clock manually
is considered a dangerous event that is specificly scheduled so issues
like you're concerned about don't happen--and someone who tinkers with the
clock without following that procedure would be in serious trouble.
You're working hard to worry about problems that should be eliminated by
the overall design of your system. If you can't trust your system clocks
and that files are being copied with their attributes intact, you should
consider thinking about how to resolve those problems rather than working
around them. It's not just PostgreSQL that will suffer from weird,
unpredictable behavior in a broken environment like that. Giving a
Windows example, if you're running in a Windows Domain configuration, if
the client time drifts too far from the server you can get "The system
cannot log you on due to the following error: There is a time difference
between the Client and Server." when trying to login.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
