Skip site navigation (1) Skip section navigation (2)

Re: Number of connections

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Raphael Bauduin <raphael(dot)bauduin(at)be(dot)easynet(dot)net>
Cc: David Busby <busby(at)pnts(dot)com>, <pgsql-php(at)postgresql(dot)org>
Subject: Re: Number of connections
Date: 2003-05-23 15:45:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-php
Actually, you can't be sure.  It is quite possible to build a system in 
PHP that will behave in unwanted ways if you leave transactions open 
across accesses.

Apache is stateless, with a thing layer of semi-statefullness layered on 
top like butter.  This is the keep alive system, which is a stock part of 
the http 1.1 spec.

What happens is that when a user accesses a web page, a certain apache 
backend gets associated to it for a short period of time.

The problem with keep alive is that apache has a short attention span, 
since the default timeout for keep alives is 15 seconds.  Let's say user A 
opens a web page with a form, and edits it for 3 minutes.  His keep alive 
connection is gone.  While it is still very likely that his next request 
will be serviced by the same child as the last time, there is NOT 

Even if the user does make the changes before the timeout, or you crank up 
the timeout to something huge like 30 minutes, they still aren't 
guaranteed to get their own child process back, as if someone requested 
access and all the other children are now tied up in keep alives or 
active requests, the apache server throws the pid of all the kept alive 
and waiting requests and randomly grabs one to service the request.  Poof, 
keep alive gone, not the same connection.

So, you can't count on always getting your old transaction back.  What you 
can do is rollback at the beginning of each script to make sure you're in 
"clean space" transactionally.

For a read only type setup, where you're tossing a cursor around, you 
might be able to check for the existence of one, but I don't know how.

On Sun, 18 May 2003, Raphael Bauduin wrote:

> A related mail I tried to post on the list yesterday but that I got
> back....
> when inserting a record in a PHP script, I sometimes use the currval
> function on the corresponding sequence to get the id of the row
> inserted.
> Maybe a stupid question, but I wondered if when using persisten
> connection, I could be sure there would be no problem. From the doc,
> currval  "Returns the value most recently obtained by nextval  for this
> sequence in the current server process."
> Can you confirm me several script using the same persistent connection
> in parallel are in separate server processes?
> Thanks.
> Raph
> On Sat, May 17, 2003 at 11:53:44AM -0700, David Busby wrote:
> > List,
> >     I cannot tell from the documentation if pg_pconnect() or pg_connect()
> > are really different in how the connection pool is managed.  Does anyone
> > know if that is the case?  Seems that using pg_pconnect would dictate "use a
> > pooled connection" and pg_connect is "use a pooled connection, or make a new
> > one".  On "live" apps which is better to use, seems pg_pconnect.  Thoughts?
> > 
> > David Busby
> > Systems Engineer
> > busby(at)pnts(dot)com
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

In response to


pgsql-php by date

Next:From: scott.marloweDate: 2003-05-23 15:58:32
Subject: Re: Number of connections
Previous:From: Mukta TelangDate: 2003-05-23 15:39:23
Subject: faster output from php and postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group