Re: regresssion script hole

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: regresssion script hole
Дата
Msg-id 4496ADAC.80007@dunslane.net
обсуждение исходный текст
Ответ на regresssion script hole  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: regresssion script hole
Следующее
От: Tom Lane
Дата:
Сообщение: Re: regresssion script hole