Skip site navigation (1) Skip section navigation (2)

Re: connection dropping

From: "James M Doherty PGADMIN" <jimmyd(at)jdoherty(dot)net>
To: <fmonkey(at)fmonkey(dot)net>, "bill" <billmac333(at)comcast(dot)net>
Cc: <pgadmin-support(at)postgresql(dot)org>
Subject: Re: connection dropping
Date: 2003-10-16 16:38:28
Message-ID: 004c01c39403$ee0dcb40$ (view raw, whole thread or download thread mbox)
Lists: pgadmin-support
If you are working from a windows machine and using putty there is a
time-out setting which you can enable.
This basically sends a null byte every (seconds you specify) to the far end.
Most firewall allow a tcp connection
but if data is not transmitted withing (firewall timeout) your connection
will be dropped by the firewall, this is
usually around 120 seconds.

----- Original Message ----- 
From: <fmonkey(at)fmonkey(dot)net>
To: "bill" <billmac333(at)comcast(dot)net>
Cc: <pgadmin-support(at)postgresql(dot)org>
Sent: Thursday, October 16, 2003 11:31 AM
Subject: Re: [pgadmin-support] connection dropping

> > Hello,
> > I love pgAdmin III. I use it when working at home. I'm stuck with II at
> > work since my machine is W98, although it (II)has a feature I prefer
> > over III. Anyway, here on the homefront, I'm connected via high-speed
> > cable connection (1.5 meg). I get excellent performance, however, I find
> > that pgAdmin drops the DB connection rather quickly if there is no
> > activity. If I leave the interface for any amount of time, when I come
> > back and click on anything, I get the error message:
> > "An error has occurred:
> >
> > server closed the connection unexpectedly
> >     This probably means the server terminated abnormally before of while
> > processing the request."
> >
> > After this I usually have to click through many dialog boxes telling me
> > that there is no connection to the server.
> >
> > If I look at the process list in the DB server, I can see all the
> > connections I have made over a period just sitting there 'idle'.
> > There is nothing in the log that corresponds with the drop that I can
> > tell except with the possibility of:
> > LOG:  pq_recvbuf: recv() failed: Connection reset by peer
> > ,but these may be from other clients.
> >
> > What can I do to maintain the connection even if its idle?
> >
> I don't know how much help I can be, but I'll see if I can give you some
> suggestions, or things to look at, to at least isolate the problem.
> Do you experience this with other applications?  I.e., if you open a ssh
> connection to a server, and leave it sitting for a while, does the session
> close/timeout?
> The odds are good that the problem here is that a router or firewall (most
> likely a firewall) between you and the database server is killing your
> connection, but not telling the server about it.  This happens quite a bit
> to me behind NAT'ing firewalls.  OTOH, behind my NAT'ing linksys cable
> router at home, my connections never time out, even if I leave them up for
> days.
> We've had the discussion before about adding support to pgAdmin3 for
> trying to keep connections alive through bad firewalls, but we've come to
> the conclusion that there isn't a "good" way to do this in the
> application, and that these sort of network problems are better solved by
> the end-user, not the application, since they are likely to affect lots of
> applications, not just pgAdmin3.
> If you can provide me some further information about your network setup,
> maybe I can give you some suggestions for trying to fix it that way.
> ahp
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>       message can get through to the mailing list cleanly

In response to

pgadmin-support by date

Next:From: James M Doherty PGADMINDate: 2003-10-16 16:39:57
Subject: Re: connection dropping
Previous:From: fmonkeyDate: 2003-10-16 16:31:22
Subject: Re: connection dropping

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