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@dbserver> psql -h 127.0.0.1 -p5432 -U user -W db This works fast. But user@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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
