Re: Psql or test application hangs when interface is down for the DB server - Mailing list pgsql-bugs

From K, Niranjan (NSN - IN/Bangalore)
Subject Re: Psql or test application hangs when interface is down for the DB server
Date
Msg-id 39C6C93FC1236641B94D3648B96E3BE70186A760@inbhexc001.nsn-intra.net
Whole thread Raw
In response to Re: Psql or test application hangs when interface is down for the DB server  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Isn't it not possible to check that the connectivity is broken in
advance and if so, wait on the socket would not be required.

If we have to timeout (even 1-2 seconds), it will be pretty long for the
highly available applications.

Is there any way to check the health of the interface?

regards,
Niranjan

-----Original Message-----
From: ext Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Wednesday, July 16, 2008 8:03 PM
To: Gregory Stark
Cc: K, Niranjan (NSN - IN/Bangalore); pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Psql or test application hangs when interface is
down for the DB server=20

Gregory Stark <stark@enterprisedb.com> writes:
> "K, Niranjan (NSN - IN/Bangalore)" <niranjan.k@nsn.com> writes:
>> Is there any other workaround or alternative so that the situation=20
>> about the interface is down is known and based on that the 'PQexec'=20
>> does not get blocked for ~15 minutes.

> Absent threads I think you have to use alarm() and a SIGALRM signal
handler.

On most modern platforms you can adjust the TCP timeouts for the
connection.  There's no explicit support for that in libpq, but you can
just get the socket FD from it and do setsockopt().

            regards, tom lane

pgsql-bugs by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping
Next
From: valgog
Date:
Subject: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping