Re: Is 1.14 supposed to behave differently when it loses connection?

From: Guillaume Lelarge

> On Wed, 2011-06-15 at 11:10 -0500, Belbin, Peter wrote:
>> Guillaume,
>>
>> Are you accessing a remote, network connected server for your
testing?
>>
>
> Nope.
>
>> If so, are you causing a network outage by disconnecting your network
connection?
>>
>
> Nope.
>
> All I can do is a fast stop of postgres. Which does the same.
Connection
> is drop without notice.
>
>> I have been seeing for a long time, on windows clients, that pgAdmin
does not behave very nicely when, for any reason, the connection is no
longer up.
>>
>> The reason for the connection not being up is typically that I am
accessing a database that is remote, and potentially sitting behind at
least a couple of layers of firewall or nat, which have their own ideas
about how long to allow a connection mappings across them valid and
functioning, so it's not really something I have direct control over,
and in any case, we're talking about how pgAdmin reacts to such an
occurrence, not how to avoid the problem.
>>
>> The bottom line is that in windows, when pgAdmin discovers that the
connection has been broken, pgAdmin most often ends up having to be
killed off and restarted. I've even gotten to the point of not even
trying to have it attempt to reconnect, because it seems that this can
fail as well.
>>
>> This issue appears to affect not only the table edit grid tool, but
the main app as well. Not sure about the sql query tool.
>>
>> Either way, the problem as a whole is quite annoying when it happens.
>>
>> Don't get me wrong, pgAdmin is great! But, this is one of it's rough
edges.
>>
>
> I understand that. But I have no answer for you.
>

Welcome to the wonderful world of MS-Windows. I have seen the same
issues for a number of Microsoft based applications. The worst case is
shared drives mapped across a busy network. It can take Windows Explorer
hours to figure out that a drive connection is no longer usable, and
every application running on the client suffers from the delays in the
meantime.

We are currently troubleshooting this problem with COM+/DCOM connections
at a client site. Like your description, theirs seems to be due to
firewalls that drop connections from their state tables long before the
applications even think about closing them. Even with keep-alives
enabled and set to a ridiculous frequency, they won't stay up.

Bob McConnell