On Fri, 1 Feb 2002, Christopher Kings-Lynne wrote:
> > Are you sure? Doesn't the httpd child process close the active connection
> > if the database/username pair is different, before opening a new one?
> > On a db with say 10000 different users, the usage of pconnect() may
> > potentially lead to 10000 * B open connections (thus postgres backends),
> > most of those completely useless...
> >
> > ... some thinking ...
> >
> > no, I was wrong:
> >
> > pgsql.max_persistent integer
> > The maximum number of persistent Postgres connections per process.
> > ^^^^^^^^^^^
>
> See the big argument I had with the PHP developers with regards to the
> crapness of their persistent connection implementation for Postgres:
>
> http://bugs.php.net/bug.php?id=13463
>
> I still don't think the guy has any idea what I'm talking about, and they've
> filed my report as 'bogus'. Very annoying...
What you want is cached persistent connections, with a specified pool size.
This way every time you need a new p-connection and the cache is full,
you just evict the LRU one from the cache and replace it with the new
one.
The only problem I see here is that you need to mark the connections
made by the *current* php script as "unclosable". Only connections
inherited by previous php scrips (running inside the same httpd child,
of course) can be safely closed. The docs clearly state that the
percieved behaviour of pconnect() is the same of connect(), and
connections can be closed any time after the script that creates
them ends. But of course connections made by the current script cannot
be closed without an explicit close() by the script itself.
>
> Chris
>
.TM.
