Postgres Pro
Downloads
Home   >   mailing lists

Re: pgAdmin hang on connection drop/reconnect - Mailing list pgadmin-support

From Willy-Bas Loos
Subject Re: pgAdmin hang on connection drop/reconnect
Date
Msg-id 1dd6057e0904230314u5ef02653w1662727951ce0e27@mail.gmail.com
Whole thread Raw
In response to Re: pgAdmin hang on connection drop/reconnect  ("Willy-Bas Loos" <willybas@gmail.com>)
Responses Re: pgAdmin hang on connection drop/reconnect  (Willy-Bas Loos <willybas@gmail.com>)
List pgadmin-support
Tree view
I looked at this problem once again with a colleage and came to the conclusion that the firewall is timing out the connection.

Some other client software packages, like SSH for example, have a mechanism to manage this problem:

"NAT firewalls like to time out idle sessions to keep their state tables clean and their memory footprint low. Some firewalls are nice, and let you idle for up to a day or so; some are gestapo and terminate your session after 5 minutes. I finally got tired of my ssh sessions getting disconnected at places where I don't control the firewalls, and figured out how to stop it. Turn out ssh has a nice inband keepalive mechanism, and even lets you set it on a per-destination basis. Just create a ~/.ssh/config file with something like the following (*kehlet.cx is shown as an example only, you might just use *): 
Host *kehlet.cx
    ServerAliveInterval 240
That's how often, in seconds, ssh will send a keepalive request (at the application layer) to the other end if the connection's been otherwise idle. 4 minutes should be good :-). The Host line lets you pattern match your destinations. Minimal effort, no impact to your system (say, as you would have if you mucked with your system's default TCP keepalive settings), and it works like a charm."


Maybe this would be a useful addition to pgAdmin?

Cheers,

WBL


On Thu, Apr 10, 2008 at 11:49 AM, Willy-Bas Loos <willybas@gmail.com> wrote:
the point i was trying to make is that pgAdmin seems to have the possibility to restore the connection, since opening a new sql window does the trick. "All you'd need to do" would be to invoke this behavior when it is necessary, without opening a new window.

cheers,

WBL


On Mon, Apr 7, 2008 at 6:18 PM, Willy-Bas Loos <willybas@gmail.com> wrote:

Hi,

We also have issues with connections ending abrubtly. Not only with pgAdmin by the way.
We're at the end of a DSL line, and the connection usually has a lot of hiccups.
After one of those hiccups, you have to wait for at least 30 seconds to find out what happened, after which you get a correct error message, and a dialog suggesting to close the server browser.
Sometimes, not quite reproducable, pgAdmin will crash instead of showing the error message.
During these 30 seconds, during which, presumably, pgAdmin waits for a server response, interaction with any of the pgAdmin windows is not possible, so that queries cannot be saved, nor can the request be cancelled.

It seems that the main window in pgAdmin is more sensitive to these hiccups than the SQL window. Sometimes (it's hard to say exactly when, because you can't notice the hiccups otherwise) the main window will not work anymore, whereas the SQL window will.
You can trick pgAdmin to reconnect by pressing the "new" button in the SQL window, the new window will have a connection (copy paste the query and close the stale window).
But it would be MUCH nicer (these hiccups are driving us crazy) if pgAdmin would be less sensitive. For example, reconnect when there is user activity after connection is lost. Also, it would be nice if there would be the option to cancel the query once you notice that the connection has been lost, and the possibility to save your work in those 30-50 secs that sometimes feel like 30 minutes.

Cheers, btw, i am a great pgAdmin fan.

WBL







On Tue, Apr 1, 2008 at 5:56 PM, Dave Page <dpage@pgadmin.org> wrote:
On Mon, Mar 31, 2008 at 9:59 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote:
> I was able to reproduce this on 1.8.2, building from source (and I get
>  the hang this time, not the segfault). A small dialog box comes up to
>  tell me something (possibly that it's about to segfault), but it's not
>  drawn correctly (presumably because the refresh drawing routines don't
>  get called correctly by that point), so I'm not sure what it says. Then
>  pgAdmin stays like this until I try to close that dialog, at which point
>  I get the "Not responding/Wait/Force Quit" dialog box from Gnome.
>
>  I noticed that I get the following on the command line where I start
>  pgadmin:
>
>  Xlib: unexpected async reply (sequence 0xf810)!

Can you get a backtrace? This might require you to build a debug enabled binary.


--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

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





--
"Patriotism is the conviction that your country is superior to all others because you were born in it." -- George Bernard Shaw

pgadmin-support by date:

Previous
From: Dave Page
Date:
Subject: Re: wrong handling of character params in debugger
Next
From: "Jan-Peter Seifert"
Date:
Subject: system database flag?