Re: Feature freeze date for 8.1

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Tuesday, May 03, 2005 4:20 PM
> To: Dave Held
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Feature freeze date for 8.1
>
>
> "Dave Held" <dave(dot)held(at)arraysg(dot)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