Re: pg_xlog - files are guaranteed to be sequentialy named? - Mailing list pgsql-general

Greg Smith wrote:
> 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,
Its not Windows; it will be Debian Linux.
I completely agree with you that of course our servers synchronize
themselve via NTP with global time, but we already had the case that -
for some reasons - NTP did not work and times drift away from each
other. If you have to manage some servers you might not recognize that a
NTP daemon does not work anymore or that a new firewall prohibits these
TCP packages now....and time goes by, because everything seem to work
just fine.
Then one nice day you realize, that one, two or many of your servers
just have their own time and you need to bring them back to synchronized
time while they are online. If you made your applications be aware of
such effects and use system-nanotime or global counters where possible,
then even these time-corrections can be handled.
But I agree with you: of course normally this will never happen...but it
happened once.
>
> 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.
yes, but still there is a remaining risk in my opinion.
> 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.
If we add a new server to the cluster, the application will check times
as it is in oyur Windows-example, but if it is allready in and working,
then it cannot simply shutdown in case of time-diffs.

Greg, thanks for your sophisticated hints.
But the thread is going a little off-topic now, I guess :)
The issue with the time-dependency of WAL archiving and deletion
issolved for me by using a global infinite counter to rely on by now.
I am sure next questions will come before long and I look forward to
read any hints then, if you and others have time to read them.
Regards Johannes