Re: Psql or test application hangs when interface is down for the DB server

I have noticed this as well. Blocks in poll(), timeout parameter -1, meanin=
g infinite then after 4 minutes on my system poll() returns 1 and=20
getsockopt() is called with SO_ERROR. SYN packets are tried only for the de=
fault tcp timeout of 20 seconds.

Consider using threads that way you can set your own timeout value.


Regards

Val

--- On Wed, 16/7/08, K, Niranjan (NSN - IN/Bangalore) <niranjan.k@nsn.com> =
wrote:

> From: K, Niranjan (NSN - IN/Bangalore) <niranjan.k@nsn.com>
> Subject: Re: [BUGS] Psql or test application hangs when interface is down=
 for the DB server
> To: "ext Tom Lane" <tgl@sss.pgh.pa.us>
> Cc: pgsql-bugs@postgresql.org
> Date: Wednesday, 16 July, 2008, 6:55 AM
> Currently the test application or the psql will unblock
> after ~15
> minutes. This is a very huge time to realize for programs
> this situation
> which do database updates.
> As far as I have debugged, I see that the execution is
> waiting on
> 'poll()' system call in the function pqSocketPoll()
> which is called as a
> result of 'PQexec()' and the timeout paramater
> provided will be -1,
> which means infinite wait time. It not clear how this is
> getting
> unblocked after 15 minutes. Who will write to the socket or
> who will
> interrupt the poll() system call?
>=20
> 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.
>=20
> regards,
> Niranjan
>=20
> -----Original Message-----
> From: ext Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
> Sent: Tuesday, July 15, 2008 8:16 PM
> To: K, Niranjan (NSN - IN/Bangalore)
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Psql or test application hangs when
> interface is
> down for the DB server=20
>=20
> "K, Niranjan (NSN - IN/Bangalore)"
> <niranjan.k@nsn.com> writes:
> > In the postgres database there is table
> 'COUNTER_TABLE' with column=20
> > integer type 'COUNTER'. The test application
> attached in this mail,=20
> > will start a transaction, gets the current value in
> the COUNTER,=20
> > increments the value and updates the incremented value
> into the
> COUNTER column.
> > This is being done in a loop. The program is started
> in a remote=20
> > client and after few transactions, the interface
> between the client &=20
> > the database server is brought down (example I used
> "ifconfig eth0=20
> > down" in the server). With this the test
> application hangs and does=20
> > not return from the API of postgres (ex.
> 'PQexec').
>=20
> If you waited long enough for the TCP connection to time
> out, it would
> return (with an error, of course).  This behavior is not a
> bug, it is
> the expected behavior of any program using a network
> connection.
>=20
>             regards, tom lane
>=20
> --=20
> Sent via pgsql-bugs mailing list
> (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs


      __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now=
 at Yahoo! http://uk.docs.yahoo.com/ymail/new.html