Re: pgAdmin hang on connection drop/reconnect

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(at)gmail(dot)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(at)gmail(dot)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(at)pgadmin(dot)org> wrote:
>>
>>> On Mon, Mar 31, 2008 at 9:59 PM, Maciek Sakrejda <msakrejda(at)truviso(dot)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(at)postgresql(dot)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