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

Re: connection dropping continued

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Markus Wollny <Markus(dot)Wollny(at)computec(dot)de>
Cc: Josh Endries <jendries(at)pragmeta(dot)com>,pgadmin-support(at)postgresql(dot)org
Subject: Re: connection dropping continued
Date: 2004-02-17 17:41:36
Message-ID: 40325250.80303@pse-consulting.de (view raw or flat)
Thread:
Lists: pgadmin-support
Markus Wollny wrote:

>Hi!
>
>  
>
>>-----Urspr√ľngliche Nachricht-----
>>Von: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
>>Gesendet: Dienstag, 17. Februar 2004 17:40
>>An: Josh Endries
>>Cc: pgadmin-support(at)postgresql(dot)org; Markus Wollny
>>Betreff: Re: [pgadmin-support] connection dropping continued
>>    
>>
>
>  
>
>>This is *not* an pgAdmin issue, any other app will suffer the same 
>>problem if crossing that firewall. 
>>    
>>
>
>You're absolutely right insofar as this is not _caused_ by PGAdmin III;
>other apps (we're using some oldish version of SQL Navigator to connect
>to an Oracle 8i DB) show the exactsame behaviour.
>
>  
>
>>Your network is broken, contact your 
>>system administrator to fix the firewall. We're using libpq, which 
>>doesn't offer such keep-alive option, because it relies on 
>>TCP/IP which 
>>by definition delivers a solid connection, unless aborted 
>>deliberately 
>>by a malfunctioning firewall or router.
>>    
>>
>
>I wouldn't call that malfunctioning, 
>

So call it ill-configured.

>the behaviour of the firewall is
>intended and does make sense, as it would open some possibilities for
>DOS-attacks if there would be no timeout.
>
>So even though it's not caused by PGAdmin III, it could be resolved in
>the application level without the need to interfere with firewalls - 
>
Wrong sight; the firewall is the interferer, screwing up tcpip. Simply 
let it forward according to RFCs, and everything's fine.

>and
>I think that there must be a lot of people who don't have sufficient
>access to their firewalls or routers in order to resolve the issue
>there. 
>
>I'm not saying that this is a vital feature for PGAdmin III to have, I'm
>not saying that the software is crappy because the connection times out.
>All I'm saying is that some sort of keep-alive-mechanism would be a
>handy feature to have in PGAdmin III. And there's really no need to
>establish some complicated mechanism on the network-protocol level to
>get the desired results
>
Wrong way; it's extra effort to *kill* the connection!

>, a simple "select 1;" issued every 30 odd
>seconds to all opened databases would be absolutely sufficient, I should
>think. If that feature is off by default and can be switched on (and
>maybe the interval adjusted according to needs), no one would be
>bothered by it either.
>
>  
>
We can not and thus will not implement app level keep-alives.
You can try to head over to pgsql-bugs or pgsql-hackers, to recommend 
implementing that in libpq, and you certainly will get the same answer: 
FIX THE FIREWALL!
The server is waiting for tcp/ip disconnect, which is never coming 
because the firewall eats this, resulting in backends waiting to death. 
Again: you'll have to request your sysadmin to fix the firewall, at 
least on that pgsql port for internal use. Timeouts simply don't make 
sense here. You won't have DOS attacks internally, I hope (if you do, 
locate the aggressor, and eliminate him).

Regards,
Andreas


In response to

pgadmin-support by date

Next:From: Matt DoggettDate: 2004-02-17 19:02:08
Subject: Re: inserting new records without OIDs
Previous:From: Markus WollnyDate: 2004-02-17 17:17:46
Subject: Re: connection dropping continued

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