Re: Establishing remote connections is slow

Hi Tom,

Thanks for your reply.

> Perhaps the problem is related to authentication - what auth mode
> are you using, and can you experiment with some other ones?

Excerpt from my pg_hba.conf

------------
local all all trust
host all all IP1/mask1 md5
host all all IP2/mask2 md5
------------

The IP/mask combinations are corresponding to the IP/subnet client is
connecting from.

Can you elaborate a bit on "experimenting"? Because I am not quite
sure what changes could possibly make any difference. Also, the fact
that when remotely connecting via standard ethernet IP address (rather
than multipath) works fine as well as this working fine short after
PostgreSQL restart, I can't see how this could be relevant.

> What I'd do to start debugging this is to get out a packet sniffer
> (wireshark or some such) and just observe the timings of packets sent
> and received by Postgres.  This would at least give you a hint which
> step is the bottleneck.

I have done some truss (strace alternative for Solaris) debugging and
it looks like it just waits for the server side to respond. I can
probably dig out where and when exactly is it waiting, but me knowing
very little about PostgreSQL internals won't help much.

Wireshark is probably not an option as this all happens on a live
server which is connected directly to a switch. I might have a look if
a tcpdump is available but chances are very limited.

> What about "psql -h localhost", ie physically local connection but
> via TCP not unix socket?

user(at)dbserver> psql -h 127.0.0.1 -p5432 -U user -W db

This works fast. But

user(at)dbserver> psql -h <IP> -p5432 -U user -W db

(where <IP> is the multipath interface)

This is slow! So it is definitely something network-related or
something how PostgreSQL deals with multipath interface.

Regards,
Mindaugas