Re: Re: [NOVICE] Re: re : PHP and persistent connections

On Mon, Nov 27, 2000 at 12:09:00PM -0500, Tom Lane wrote:
>
> I'm still not following exactly what people think would happen if we did
> have such a "feature". OK, the backend times out after some interval
> of seeing no activity, and disconnects. How is the client going to
> react to that, exactly, and why would it not conclude that something's
> gone fatally wrong with the database?

Because a lot of commercial (and other) databases have this "feature",
a lot of well behaved apps (and middleware packages) already know how
to deal with it: i.e. try to reconnect, and continue. If that fails,
throw an error.

> Seems to me that you still end up having to fix the client, and that
> in the last analysis this is a client issue, not something for the
> backend to hack around.

It's already fixed, see above. In addition, your assuming the same
administrative entity has control over the clients and the backend.
This is not always the case. For example, in a web hosting environment.
Then, the DBA has the responsibiltiy to ensure minimal interference
between different customers.

As it stands, the client that causes the problem sees no problem to
fix: other clients get 'that damn PostgreSQL backend quits accepting
connections', and yell at the DBA. So, the DBA wants a way to propagate
the 'problem' to the clients that cause it, by timing out the idle
connections. Then, those clients _will_ fix their code, if it doesn't
already do it for them, as per above.

Basically, PostgreSQL is being too polite: it's in the clients interest to
keep the connection open, since it minimizes response time, regardless
of how this might affect other backends. It's cooperative vs. hard
multitasking, all over again.

Clients and servers optimize for different parameters: the client wants
minimum response time for it's requests. The backend wants minimum
_average_ response time, over all requests.

Ross
--
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers
and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.