From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: regresssion script hole |
Date: | 2006-06-19 13:44:44 |
Message-ID: | 4496AA4C.7090704@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> The question isn't whether is succeeds, it's how long it takes to
>> succeed. When I increased the pg_regress timeout it actually went
>> through the whole regression test happily. I suspect we have 2 things
>> eating up the 60s timeout here: loading the timezone db and resolving
>> whatever it is we are trying to resolve.
>
> The behavior of loading the whole TZ database was there for awhile
> before anyone noticed; I believe it could only be responsible for a
> few seconds. So the failed DNS responses must be the problem. Could
> we get a ktrace with timestamps on the syscalls to confirm that?
>
> Of course the $64 question is *why* is 8.0 trying to resolve that name,
> particularly seeing that the later branches apparently aren't.
hmm maybe the later branches are trying to resolve that too - but only
the combination of the TZ database loading + the failed DNS-queries is
pushing the startup time over the 60 second limit on this (quite slow) box ?
I will try to verify what the later branches are doing exactly ...
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-19 13:49:03 | Re: regresssion script hole |
Previous Message | Giampaolo Tomassoni | 2006-06-19 13:41:02 | R: R: Per-server univocal identifier |