| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: regresssion script hole |
| Date: | 2006-06-19 13:21:21 |
| Message-ID: | 18364.1150723281@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:
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-06-19 13:29:29 | Re: regresssion script hole |
| Previous Message | Joachim Wieland | 2006-06-19 13:18:20 | Re: R: Per-server univocal identifier |