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>, Jasmin Dizdarevic <jasmin(dot)dizdarevic(at)gmail(dot)com>
Subject: Re: Handling connection loss
Date: 2011-07-19 18:47:28
Message-ID: 1311101248.2036.68.camel@laptop (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Tue, 2011-07-19 at 10:56 +0100, Dave Page wrote:
> On Tue, Jul 19, 2011 at 10:19 AM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info> wrote:
> > On Tue, 2011-07-19 at 09:53 +0100, Dave Page wrote:
> >> On Mon, Jul 18, 2011 at 9:11 PM, Guillaume Lelarge
> >> <guillaume(at)lelarge(dot)info> wrote:
> >> >
> >> > 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.
> >>
> >> Was the second object in the same database? Don't forget that we might
> >> have to restore multiple connections to individual databases, and the
> >> maintenance DB - and we only test them when we need them.
> >>
> >
> > It was the same one.
> 
> Hmm. Not sure why that would happen. Do you recall what the object types were?
> 

Tables and schemas.

> >> > 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.
> >>
> >> I was testing using Josh's SSH tunnel test primarily, so that worked
> >> well for me. Can you describe the steps to reproduce the issue?
> >>
> >
> > Create an SSH tunnel (for example like this ssh -L 2000:127.0.0.1:5432
> > myuser(at)my_ip).
> >
> > Launch PgAdmin, open a connection with server localhost, port 2000. You
> > should be able to connect to a database. Then, go to your terminal, drop
> > the tunnel connection, and then reopen the tunnel connection. Go back to
> > the browser, click on some objects. pgAdmin didn't ask if I want to
> > reconnect.
> 
> That's basically how I've been testing it. I wonder if you're getting
> confused by the fact that not all object types will access the
> database when clicked (and others won't access the database if they've
> previously been clicked or expanded), thus won't necessarily cause a
> connection check to occur.
> 

No, it was tables too.

> Do you see any cases where the connection isn't checked and bad things
> happen? Or just cases where you expected a check, but don't see one.
> 
> BTW; thanks to both you and Jasmin for testing.
> 
> 

I tried something else today. Suppose a database with two schemas. Both
have objects in them, let's say two tables in each schema. Connect to
the database, click on the + of the first schema. You'll see all objects
in it. Now, restart PostgreSQL. And click on the + of the second schema.
It'll tell you you're disconnected and will ask you if you want to
reconnect. You say yes, it reconnects and you'll see all the objects
types with nothing ("Tables (0)" for example instead of "Tables (2)").
If you refresh the schema, you'll have the right info (ie, "Tables
(2)").

BTW, I used the v2 patch.


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


In response to

Responses

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2011-07-19 18:50:45
Subject: Re: pgAdmin III commit: Database Designer (milestone 1 of GSoC 2011)
Previous:From: Dave PageDate: 2011-07-19 09:56:48
Subject: Re: Handling connection loss

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