> > 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 t
I wrote:
> 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've filed a bug for this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171351
so no nee
Andrew Dunstan <[EMAIL PROTECTED]> 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 cl
Tom Lane wrote:
So there's some Heisenberg effect here. However, I don't think there
can be much doubt that on a machine that is just booting (and has
surely got none of these files in cache) the search through
share/postgresql/timezone could take a few seconds. Hindsight is
always 20/20 ;-)
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In short: pg_timezone_initialize() took about 8.2 seconds out of the
>> total time of 8.73 seconds.
> Further data points:
> I just observed this taking over 20 seconds on my clunky old pII 266.
> That's really horrible. But pg_ctl
Tom Lane wrote:
In short: pg_timezone_initialize() took about 8.2 seconds out of the
total time of 8.73 seconds.
Since pg_timezone_initialize() needs to scan all of the 500-odd files
under postgresql/share/timezone/, it isn't so surprising that it would
take a little bit of time. But 8 seco
Tony Caduto <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Are you willing to try strace'ing the postmaster?
> I added the strace line like you said and rebooted, it did display the
> [FAILED] after the reboot.
Thanks for collecting the raw data. The salient events seem to be these:
12:57:52
Tom Lane wrote:
Tony Caduto <[EMAIL PROTECTED]> writes:
I tried changing the sleep command in the script to 2, but at boot it
still says [FAILED].
even though the script reports it failed, the db is up an running.
This seems to happen for some people and not others. I've been wantin
Tony Caduto <[EMAIL PROTECTED]> writes:
> I tried changing the sleep command in the script to 2, but at boot it
> still says [FAILED].
> even though the script reports it failed, the db is up an running.
This seems to happen for some people and not others. I've been wanting
to find out how the h
Hi all,
I tried changing the sleep command in the script to 2, but at boot it
still says [FAILED].
even though the script reports it failed, the db is up an running.
System is a Compaq DL380(2.5gb ram 2.4 dual 2.4gzh Xeon) running CentOS 4.2
I am going to install 8.1beta 3 on another box that
Hi,
On Tue, 18 Oct 2005, Tony Caduto wrote:
I installed 8.04 via RPM on Centos 4.2 which is the same as RedHat 4.2 and
while booting the init script reports that the daemon [FAILED], but after I
logon it shows the postmaster running and I am able to connect from any
client remotely.
I made
11 matches
Mail list logo
