Re: 8.04 and RedHat/CentOS init script issue and sleep

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.04 and RedHat/CentOS init script issue and sleep
Date: 2005-10-20 21:33:27
Message-ID: 14231.1129844007@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Something is surely wrong in the timezone lib, though:

[ digs in glibc sources for awhile... ]

The test loop in score_timezone() calls both localtime() and strftime()
for each probe point, and in glibc strftime() calls tzset(), which the
source code claims is required by POSIX. The explicit tzset() call is
what's forcing the recheck of /etc/localtime.

Possibly the glibc boys would listen to a suggestion that strftime()
need not force the file recheck, but my experience with them is that
they're relatively impervious to suggestions :-(

I'm not actually particularly worried about the startup time. What's
bothering me right at the moment, given the new-found knowledge that
strftime() is slow on Linux, is that we're using it in elog(). At the
time that code was written, we did it deliberately to ensure that all
the backends would write log timestamps in the same timezone regardless
of local SET TimeZone commands. That's still an important
consideration, but I wonder whether we don't now have enough timezone
infrastructure that we could get the same results using pg_strftime.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-20 21:35:31 Re: Seeing context switch storm with 10/13 snapshot of
Previous Message Dann Corbit 2005-10-20 21:24:26 Re: [GENERAL] 'a' == 'a '