From: | "Medora Schauer" <mschauer(at)fairfield(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Michael Fuhr" <mike(at)fuhr(dot)org> |
Cc: | "Bruno Wolff III" <bruno(at)wolff(dot)to>, "postgresql" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: hyper slow after upgrade to 8.1.4 |
Date: | 2006-07-13 18:25:03 |
Message-ID: | 1CA058827877644DAB54FB930FFA3B05A67C31@lincoln.FAIRIND.FAIRFIELD.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Thursday, July 13, 2006 11:12 AM
>
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> > On Thu, Jul 13, 2006 at 08:22:46AM -0500, Medora Schauer wrote:
> >> Can it be that the connection delay is because first an IPv6 socket
is
> >> trying to be established and when that fails an IPv4 socket is
created?
>
> > A sniffer like tcpdump or ethereal might reveal why connecting is
> > so slow.
>
> I'd try strace'ing the client process first --- whatever is slow might
> not be exposed as TCP traffic. It does sound though that the problem
> is related to userland expecting IPv6 support that the kernel doesn't
> actually have.
>
> regards, tom lane
Good idea Tom. Strace showed communications with a machine that didn't
make sense. Turns out someone had configured DNS on the "slow" machine
but the DNS server wasn't running. When I use the IP address of the PG
server rather than the name with psql, the connection is made quickly.
Thanks for all the help everyone,
Medora Schauer
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-13 22:32:58 | Re: Problem with bitmap-index-scan plan |
Previous Message | Tom Lane | 2006-07-13 17:42:41 | Re: size of pg_dump files containing bytea values |