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
|
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>
Did some tests and found something weird. I connect pgadmin to aOn 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 :-)
>
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: