Skip site navigation (1) Skip section navigation (2)

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

From: Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk>
To: ext Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "K, Niranjan \(NSN - IN/Bangalore\)" <niranjan(dot)k(at)nsn(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Psql or test application hangs when interface is down for the DB server
Date: 2008-07-16 14:52:50
Message-ID: 266574.35866.qm@web25806.mail.ukl.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

Responses

pgsql-bugs by date

Next:From: Gregory StarkDate: 2008-07-16 17:33:23
Subject: Re: Psql or test application hangs when interface is down for the DB server
Previous:From: Tom LaneDate: 2008-07-16 14:33:07
Subject: Re: Psql or test application hangs when interface is down for the DB server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group