Re: Feature freeze date for 8.1 - Mailing list pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Dave Held
> Sent: Tuesday, May 03, 2005 3:41 PM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > Sent: Tuesday, May 03, 2005 4:20 PM
> > To: Dave Held
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Feature freeze date for 8.1
> >
> >
> > "Dave Held" <dave.held@arraysg.com> writes:
> > > How about an optional second connection to send keepalive pings?
> > > It could be unencrypted and non-blocking.  If authentication is
> > > needed on the ping port (which it doesn't seem like it would need
> > > to be), it could be very simple, like this:
> >
> > > * client connects to main port
> > > * server authenticates client normally
> > > * server sends nonce token for keepalive authentication
> > > * client connects to keepalive port
> > > * client sends nonce token on keepalive port
> > > * server associates matching keepalive connection with main
> > >     connection
> > > * if server does not receive matching token within a small
> > >     timeout, no keepalive support enabled for this session
> >
> >
> > This seems to have nothing whatever to do with the stated problem?
>
> I thought the problem was a server process that loses a
> connection to a client sticking around and consuming resources.
> And then I thought a possible solution was to try to see if
> the client is still alive by sending it an occasional packet.
> And then I thought a new problem is sending packets to an
> unresponsive client and filling up the output buffer and
> blocking the server process.
>
> So it seems that a possible solution to that problem is to
> have a separate connection for keepalive packets that doesn't
> block and doesn't interfere with normal client/server
> communication.
>
> Now granted, it is possible that the primary connection could
> die and the secondary is still alive.  So let's consider the
> likely failure modes:
>
> * physical network failure
>
> In this case, I don't see how the secondary could survive while
> the primary dies.
>
> * client hangs or dies
>
> If the client isn't reading keepalives from the server,
> eventually the server's send queue will fill and the server
> will see that the client is unresponsive.  The only way the
> client could fail on the primary while responding on the
> secondary is if it makes the connections in different threads,
> and the primary thread crashes somehow.  At that point, I would
> hope that the user would notice that the client has died and
> shut it down completely.  Otherwise, the client should just not
> create a separate thread for responding to keepalives.
>
> * transient network congestion
>
> It's possible that a keepalive could be delayed past the
> expiration time, and the server would assume that the client
> is dead when it's really not.  Then it would close the client's
> connection rather rudely.  But then, since there's no reliable
> way to tell if a client is dead or not, your other option is to
> consume all your connections on maybe-dead clients.
>
> So what am I missing?
>
> __
> David B. Held
> Software Engineer/Array Services Group
> 200 14th Ave. East,  Sartell, MN 56377
> 320.534.3637 320.253.7800 800.752.8129
>

1)  Adding a separate connection means managing that connection, making
sure it gets connected/disconnected at the right times, and that it can
traverse the same firewalls as the primary connection.

2)  You'd need another process or another thread to respond on the
secondary connection.  If it's another process, the primary process
could die/hang while the keepalive process keeps working (or vice
versa).  If it's another thread, you are forcing all clients to support
multithreading.