Uh, Don?
Not all the world's a web page, you know. Thatkind of thinking is _so_
mid 90's ;-) Dedicated apps that talk directly the user seem to be making
a comeback, due to a number of factors. They can have much cleaner user
interfaces, for example.
Which brings us back around to the point of why this is on Hackers:
PostgreSQL currently has no clean method for dropping idle connections.
Yes, some apps handle this themselves, but not all. A number of people
seem to feel there is a need for this feature. How hard would it be to
implement?
Probably not too hard: we've already got an 'idle' state, suring which we
block on the input. Add a timeout to hat, and we're pretty much there.
<goes and looks at code for a bit>
Hmm, we're down in the bowels of libpq, doing a recv() on the socket
to the frontend, about 4 layers down from backend's blocking call to
ReadCommand(). I seem to recall someone working on creating an async
version of the libpq API, but Tom not being happy with the approach.
So, it's not a simple change.
Ross
On Mon, Nov 27, 2000 at 07:18:48AM -0800, Don Baccus wrote:
> At 12:38 AM 11/27/00 -0700, Ron Chmara wrote:
> >Don Baccus wrote:
> >> At 12:07 AM 11/26/00 -0500, Alain Toussaint wrote:
> >> >how about having a middle man between apache (or aolserver or any other
> >> >clients...) and PosgreSQL ??
> >> >that middleman could be configured to have 16 persistant connections,every
> >> >clients would deal with the middleman instead of going direct to the
> >> >database,this would be an advantage where multiple PostgreSQL server are
> >> >used...
> >> Well, this is sort of what AOLserver does for you without any need for
> >> middlemen.
> >
> >What if you have a server farm of 8 AOL servers, and 12 perl clients, and
> >3 MS Access connections, leaving things open? Is AOLserver parsing the
> >Perl DBD/DBI, connects, too? So you're using AOLserver as (cough) a
> >middleman? <g>
Note that only the AOL servers here are web client/servers, the rest are
dedicated apps.
<snip Don missing the point>
--
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.
