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, 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) <niranjan(dot)k(at)nsn(dot)com> wrote:

> From: K, Niranjan (NSN - IN/Bangalore) <niranjan(dot)k(at)nsn(dot)com>
> Subject: Re: [BUGS] Psql or test application hangs when interface is down for the DB server
> To: "ext Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc: pgsql-bugs(at)postgresql(dot)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:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Tuesday, July 15, 2008 8:16 PM
> To: K, Niranjan (NSN - IN/Bangalore)
> Cc: pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] Psql or test application hangs when
> interface is
> down for the DB server
>
> "K, Niranjan (NSN - IN/Bangalore)"
> <niranjan(dot)k(at)nsn(dot)com> 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(at)postgresql(dot)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