Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> 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 tim
Tom Lane wrote:
Oh, I think I see the problem:
8.0 pg_regress:
if [ "$unix_sockets" = no ]; then
postmaster_options="$postmaster_options -c listen_addresses=$hostname"
else
postmaster_options="$postmaster_options -c listen_addresses=''"
fi
8.1 pg_regress:
if [
I wrote:
> 8.0 pg_regress:
> postmaster_options="$postmaster_options -c listen_addresses=''"
> 8.1 pg_regress:
> postmaster_options="$postmaster_options -c listen_addresses="
and in fact here's the commit that changed that:
2005-06-19 22:26 tgl
* src/test/regress/pg_regr
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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 thin
Oh, I think I see the problem:
8.0 pg_regress:
if [ "$unix_sockets" = no ]; then
postmaster_options="$postmaster_options -c listen_addresses=$hostname"
else
postmaster_options="$postmaster_options -c listen_addresses=''"
fi
8.1 pg_regress:
if [ "$unix_sockets" =
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> I tcpdump'd the dns-traffic on that box during a postmaster startup and
> it's definitly trying to look up ''.kaltenbrunner.cc a lot of times.
I just strace'd postmaster start on a Fedora box and can see nothing
corresponding. Since this is a "ma
Martijn van Oosterhout wrote:
> On Mon, Jun 19, 2006 at 09:21:21AM -0400, Tom Lane wrote:
>> Of course the $64 question is *why* is 8.0 trying to resolve that name,
>> particularly seeing that the later branches apparently aren't.
>
> The formatting of the message suggests it is a gethostbyname("'
On Mon, Jun 19, 2006 at 09:21:21AM -0400, Tom Lane wrote:
> Of course the $64 question is *why* is 8.0 trying to resolve that name,
> particularly seeing that the later branches apparently aren't.
The formatting of the message suggests it is a gethostbyname("''")
doing it. Did any quoting rules ch
Andrew Dunstan <[EMAIL PROTECTED]> 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
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
Why are we actually looking up anything? Just so we can bind to a
listening socket?
Anyway, maybe the box needs a lookup line in its /etc/resolv.conf to
direct it to use files first, something like
lookup file bind
Stefan, can you look i
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
>> Anyway, the tail end of the trace
>> shows it repeatedly sending off a UDP packet and getting practically the
>> same data back:
>>
>>
>> I'm not too up on what the DNS protocol looks like on-the-wire, but I'll
>> bet this is it. I think it's try
Michael Fuhr wrote:
> On Sun, Jun 18, 2006 at 07:18:07PM -0600, Michael Fuhr wrote:
>> Maybe I'm misreading the packet, but I think the query is for
>> ''kaltenbrunner.cc (two single quotes followed by kaltenbrunner.cc)
>
> Correction: ''.kaltenbrunner.cc
yes that is exactly the issue - the postm
On Sun, Jun 18, 2006 at 07:18:07PM -0600, Michael Fuhr wrote:
> Maybe I'm misreading the packet, but I think the query is for
> ''kaltenbrunner.cc (two single quotes followed by kaltenbrunner.cc)
Correction: ''.kaltenbrunner.cc
--
Michael Fuhr
---(end of broadcast)--
On Sun, Jun 18, 2006 at 07:50:04PM -0400, Tom Lane wrote:
> 24583 postgres CALL
> recvfrom(0x3,0x477e4000,0x1,0,0xfffe4da0,0xfffe4d5c)
> 24583 postgres GIO fd 3 read 37 bytes
>"\M-Sr\M^A\M^B\0\^A\0\0\0\0\0\0\^B''\rkaltenbrunner\^Bcc\0\0\^A\0\^A"
> 24583 postgres R
Tom Lane wrote:
Anyway, the tail end of the trace
shows it repeatedly sending off a UDP packet and getting practically the
same data back:
I'm not too up on what the DNS protocol looks like on-the-wire, but I'll
bet this is it. I think it's trying to look up "kaltenbrunner.cc" and
failing.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One idea that comes to mind is a DNS lookup timeout. Can you strace the
>> postmaster to see what it's doing?
> There is ktrace output I managed to capture at
> http://developer.postgresql.org/~adunstan/ktrace.txt
> Not sure what it
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We need both, I think. I am still trying to find out why it's taking so
long. This is on the 8.0 branch, though. Later branches seem to be working.
One idea that comes to mind is a DNS lookup timeout. Can you strace the
pos
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We need both, I think. I am still trying to find out why it's taking so
> long. This is on the 8.0 branch, though. Later branches seem to be working.
One idea that comes to mind is a DNS lookup timeout. Can you strace the
postmaster to see what it's d
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The problem is that if the postmaster takes more than 60 seconds to
start listening (as is apparently happening on spoonbill - don't yet
know why) this code falls through.
If the postmaster takes that long to start listenin
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The problem is that if the postmaster takes more than 60 seconds to
> start listening (as is apparently happening on spoonbill - don't yet
> know why) this code falls through.
If the postmaster takes that long to start listening, I'd say we need to
fi
While investigating some problems with buildfarm member spoonbill I came
across this piece of code in pg_regress.sh, which seems less than robust:
# Wait till postmaster is able to accept connections (normally only
# a second or so, but Cygwin is reportedly *much* slower). Don't
# w
21 matches
Mail list logo
