php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #12558 pgsql connections apparently not being closed
Submitted: 2001-08-03 13:47 UTC Modified: 2001-12-26 07:05 UTC
From: zeekamotay at hotmail dot com Assigned:
Status: Closed Package: PostgreSQL related
PHP Version: 4.0.5 OS: linux
Private report: No CVE-ID: None
 [2001-08-03 13:47 UTC] zeekamotay at hotmail dot com
web server: RedHat 7.0, kernel 2.2, Apache 1.3.20, PHP 4.0.5
db server: RedHat 6.2, kernel 2.2, Postgres 7.1.2

configure:
./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-config-file-path=/usr/local/apache/conf \
--disable-xml \
--disable-pear \
--enable-magic-quotes \
--with-curl \
--with-imap \
--without-mysql \
--with-pgsql=/usr/local/pgsql \
--enable-trans-sid \
--with-regex=php \
--enable-memory-limit \

problem:

PHP is apparently not always closing connections to the database server.

At any time, the number of Postgres processes running on the database server will be 20-100% more than the number of httpd processes running on the web server.

Eventually, the database server will hit its maximum number of concurrent connections allowed, and deny further access, even though 90+% of the running Postgres processes are idle.

This problem exists whether or not I use persistent connections. Turning off Apache keepalives seems to make the problem much less dramatic (i.e., it takes a lot longer to eventually hit the max connections), but it doesn't cure it.

This problem occurs with PHP 4.0.4pl1 and 4.0.6, and Postgres 7.0.3, as well. Don't know where to turn next... any ideas? Thanks.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-05 18:49 UTC] yohgaki@php.net
Could you try 4.1.0RC5? 
http://www.php.net/~zeev/php-4.1.0RC5.tar.gz
 [2001-12-26 07:05 UTC] lobbin@php.net
No feedback. Closing.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 06:01:32 2024 UTC