Re: Handling connection loss

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(at)lelarge(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>