I have noticed this as well. Blocks in poll(), timeout parameter -1, meaning infinite then after 4 minutes on my system poll() returns 1 and getsockopt() is called with SO_ERROR. SYN packets are tried only for the default 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) <[EMAIL PROTECTED]> wrote: > From: K, Niranjan (NSN - IN/Bangalore) <[EMAIL PROTECTED]> > Subject: Re: [BUGS] Psql or test application hangs when interface is down for > the DB server > To: "ext Tom Lane" <[EMAIL PROTECTED]> > 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? > > 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. > > regards, > Niranjan > > -----Original Message----- > From: ext Tom Lane [mailto:[EMAIL PROTECTED] > 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 > > "K, Niranjan (NSN - IN/Bangalore)" > <[EMAIL PROTECTED]> writes: > > In the postgres database there is table > 'COUNTER_TABLE' with column > > integer type 'COUNTER'. The test application > attached in this mail, > > will start a transaction, gets the current value in > the COUNTER, > > 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 > > client and after few transactions, the interface > between the client & > > the database server is brought down (example I used > "ifconfig eth0 > > down" in the server). With this the test > application hangs and does > > not return from the API of postgres (ex. > 'PQexec'). > > 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. > > regards, tom lane > > -- > 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
