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?
From: ext Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, July 16, 2008 8:03 PM
To: Gregory Stark
Cc: K, Niranjan (NSN - IN/Bangalore); pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] Psql or test application hangs when interface is
down for the DB server
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "K, Niranjan (NSN - IN/Bangalore)" <niranjan(dot)k(at)nsn(dot)com> writes:
>> Is there any other workaround or alternative so that the situation
>> about the interface is down is known and based on that the 'PQexec'
>> does not get blocked for ~15 minutes.
> Absent threads I think you have to use alarm() and a SIGALRM signal
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
In response to
pgsql-bugs by date
|Next:||From: valgog||Date: 2008-07-25 14:15:36|
|Subject: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping|
|Previous:||From: Zdenek Kotala||Date: 2008-07-25 08:17:56|
|Subject: Re: BUG #4319: lower()/upper() does not know about UNICODE case