Message-ID: <3A532CC0.847FF3C7@joerdens.de>
Date: Wed, 03 Jan 2001 14:44:32 +0100
From: Frank Joerdens <frank@joerdens.de>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tom Samplonius <tom@sdf.com>, mlw <markw@mohawksoft.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: [INTERFACES] Re: PHP and PostgreSQL
References: <Pine.BSF.4.05.10101022030040.8582-100000@misery.sdf.com>
	<15332.978502036@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
[ . . . ]
> A general-purpose connection-reuse facility on the server end cannot
> eliminate these overheads, whereas it's trivial to avoid them within
> the context of a multi-threaded client.

PHP 4.04 does provide support for AOLServer now (which is multithreaded). I haven't had
time to play with it, and it moreover isn't certified for production use yet:

---------------------------------- snip ----------------------------------
NOTE: You should not use this module in production. PHP is not 100% stable
      yet in threaded mode. To increase reliability enable the Global Lock
      by removing #define NO_GLOBAL_LOCK in main/main.c. Also don't use
      php_value as it will lead to races in a sub-system (use an ini file
      instead).
---------------------------------- snap ----------------------------------
(from the php/sapi/aolserver/README)

But it might be the way to go forward with the connection pooling issue. Maybe the PHP
people could use some help from the Postgres developers there? I think it has been pointed
out in the context of this thread that Apache, as a multi-process server, could not
properly handle connection pooling because it's not feasible to pool connections across
several Apache children (or was that the problem?).

Regards, Frank