Re: Handling connection loss - Mailing list pgadmin-hackers

From Jasmin Dizdarevic
Subject Re: Handling connection loss
Date
Msg-id CAOveQuNnSH17EcowEy8pHmbP=7fy8oA155+Uv6_UddRkLGW+kw@mail.gmail.com
Whole thread Raw
In response to Re: Handling connection loss  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: Handling connection loss  (Dave Page <dpage@pgadmin.org>)
List pgadmin-hackers
There are some unexpected errors, when reconnecting.

1. Open Function collection, shutdown DB, click on a function: Result: stacktrace.png
2. Open Table collection, shutdown DB, click on a table, start DB, reconnect: Result: stacktrace2.png

Can't we include a third layer between application and database code, which handle's corrupt connections?

2011/7/18 Guillaume Lelarge <guillaume@lelarge.info>
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


--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Attachment

pgadmin-hackers by date:

Previous
From: Jasmin Dizdarevic
Date:
Subject: Re: Website
Next
From: "pgAdmin Trac"
Date:
Subject: Re: [pgAdmin III] #328: Column collation change has no effect