Bug #13463 Updated: Persistent connections with different usernames not being reused
| From: | chriskl at familyhealth dot com dot au | Date: | Thu, 06 Dec 2001 02:48:49 +0000 |
| Subject: | Bug #13463 Updated: Persistent connections with different usernames not being reused | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-72709@lists.php.net to get a copy of this message | ||
ID: 13463
User updated by: chriskl@familyhealth.com.au
Reported By: chriskl@familyhealth.com.au
Status: Bogus
Bug Type: PostgreSQL related
Operating System: FreeBSD 4.4
PHP Version: 4.0.6
New Comment:
Yes, but my point is that imagine this situation:
40 different usernames for the database
32 maximum connections to the database
It doesn't take much to figure out what's going to happen. As soon as the first 32
usernames to be used have created persistent connections, the further 8 usernames can never pconnect
-> and remember, that doesn't take into account the fact that there are multiple PHP
processes running.
So, what I am suggesting is that once all 32 connections are being used and PHP then attempts to use
a 33rd username, instead of refusing to open the connection you should destroy the least recently
used persistent connection. This could be inefficient, but at least it won't lock PHP out of
Postgres.
Chris
Previous Comments:
------------------------------------------------------------------------
[2001-12-05 18:59:06] yohgaki@php.net
This is a design.
Connection parameters must be the same to reuse existing persistent connection. This design is
useful when you have multiple transactions.
------------------------------------------------------------------------
[2001-09-26 21:44:30] chriskl@familyhealth.com.au
We never had a problem with persistent connections until we started using about 40 different db
usernames/passwords for different scripts on our site, to give the scripts fine grained permissions.
Now, the problem is that we rapidly get 40 postmasters appearing, that are not reused. The solution
was to switch back to non-persistent connections and everything is hunky dory.
I'm fairly certain this problem started appearing in a recent PHP release as one day it
wasn't doing it and one day it was, and PHP was upgraded on our servers arount that time.
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=13463&edit=1