Re: hyper slow after upgrade to 8.1.4

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

Browse pgsql-performance by date

  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