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

Re: Handling connection loss

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Handling connection loss
Date: 2011-07-18 20:11:34
Message-ID: 1311019895.2008.30.camel@laptop (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Mon, 2011-07-18 at 15:18 +0100, Dave Page wrote:
> I've been sufficiently annoyed by Josh's discovery that the
> reconnection changes in 1.14 are still broken in some situations that
> I've spent most of the day hacking on this. It's become pretty clear
> to me that the current code structure really doesn't lend itself to
> cleanly handling all possible disconnection scenarios - every time I
> managed to fix one potential problem area I found another - and then
> realised that I was building connection handling code into all sorts
> of unrelated places where it really shouldn't be.
> 
> So, I bit the bullet and moved all the reconnection code into the low
> level database classes. Originally I shied away from that due to the
> need to throw up message boxes, but I'm pretty much convinced now that
> that is the lesser of the evils. So, the attached patch (against
> REL-1_14_0_PATCHES) centralises the connection test code into on
> function in pgConn:CheckConnection, which will check the connection
> and allows the user to reconnect if desired. All the other pgConn
> functions that use the database connection (except those doing the
> setup) now call that function upon entry, as do most of the places in
> other parts of the app that used to do some form of connection
> checking.
> 
> The one downside to this design is that failure to reconnect
> constitutes a fatal error, as there's no way from the low level
> database classes that we can cleanup state in the higher levels. It's
> not quite as bad as it initially sounds though - the user can request
> infinite connection retries; it only exits when they hit "No" to the
> reconnect prompt (which is clear that doing so will be fatal).
> 
> I'm proposing this for 1.14, however I'm aware it's a big change, and
> it's late in the cycle. I'd therefore like lots of review and testing
> please :-)
> 

Did some tests and found something weird. I connect pgadmin to a
database, I look into some objects with pgAdmin's browser. Then, I stop
PostgreSQL, and start it again. Next object I click on will display a
nice "lost connection" message, and another messagebox asking me if I
want to reconnect. I click Yes and everything seems good (iow, I have
the info I asked). I then click on another object, and it asks me again
if I want to reconnect. Weird. I click Yes, and I get reconnected, and I
won't be bothered again. I find it weird to have to say Yes two times
when the connection was lost only once.

Moreover, with the SSH tunnel as described by Christophe Chauvet on
-support, I don't even have the message box asking me if I want to
reconnect.


-- 
Guillaume
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com


In response to

Responses

pgadmin-hackers by date

Next:From: pgAdmin TracDate: 2011-07-18 20:12:57
Subject: Re: [pgAdmin III] #329: Duplicate column names allowed
Previous:From: Thom BrownDate: 2011-07-18 20:06:25
Subject: Re: Prevent duplicate attributes

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