php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13463 Persistent connections with different usernames not being reused
Submitted: 2001-09-26 21:44 UTC Modified: 2001-12-06 00:05 UTC
From: chriskl at familyhealth dot com dot au Assigned:
Status: Not a bug Package: PostgreSQL related
PHP Version: 4.0.6 OS: FreeBSD 4.4
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: chriskl at familyhealth dot com dot au
New email:
PHP Version: OS:

 

 [2001-09-26 21:44 UTC] chriskl at familyhealth dot com dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-05 18:59 UTC] 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-12-05 21:48 UTC] chriskl at familyhealth dot com dot au
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

 [2001-12-05 22:22 UTC] yohgaki@php.net
I understand your problem, but I think resuing existing connection that has  different connection parameter will be a cause of hard to find bug or even a security hole.

Older PostgreSQL accepts really few number of connections. 7.1.x supports upto 1024 connections by default (You need to edit postgresql.conf)   I suggest to upgrade your server....

--
Yasuo Ohgaki
 [2001-12-05 22:44 UTC] chriskl at familyhealth dot com dot au
I don't propose re-using an existing connection with different parameters at all!  What I'm saying is that if PHP hits the max database pconnections, and it needs to open another, then it should destroy an old one, and then create the new one, rather than just dying.

I use PHP 7.1.3, with 64 simultaneous connections.  It's not feasible to up to 1024 connections as you need to allocate a heap of shared memory buffers, equivalent to double the max connections.

Anyway, the solution is not to tell someone to 'increase their max connections', the solution is to fix the problem...
 [2001-12-06 00:05 UTC] yohgaki@php.net
Does other db module close persistent connection if number of persistent connections reache max persistent connections? Closing connection can be a problem, though.

Anyway, If you use all connection to pgsql with persistent connection, you cannot make any new connections obviously.  Therefore,  there is php.ini entry to limit max number of persistent connections.

If other db modules close persistent connections when max persistent connection is reached, I'll work on it.  (If it feasible)


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 14:01:28 2024 UTC