Re: regresssion script hole - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: regresssion script hole
Date
Msg-id 4496ADAC.80007@dunslane.net
Whole thread Raw
In response to regresssion script hole  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
>   
>> Andrew Dunstan <andrew@dunslane.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 ...
>
>
>   

Yes, we're on the margin here. The successful runs I saw got through the 
timeout in 5 or 10 seconds over the 60 that we currently allow.

What interests me is where it even gets the string 'kaltenbrunner.cc' 
from. It looks to me like the most likely place is the search line in 
/etc/resolv.conf. Ir would be nice to know exactly what it is trying to 
resolve.

cheers

andrew

cheers

andrew



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: regresssion script hole
Next
From: Tom Lane
Date:
Subject: Re: regresssion script hole