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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
