If you're used to a traditional client/server arrangement, there are some things you need to be aware of when running with a web-server.
You can't maintain a connection and therefore a transaction between requests for web-pages.
You have similar issues with user authentication.
You no longer have a 1:1 correspondence between users and connections - the ratio can vary either way.
Long-lived queries will need to be handled differently from interactive ones.
The web offers a different application model to classic client/server. Traditionally, a client application connects, authenticates, performs operations then disconnects. The web is not session-based, and only knows about requests for individual objects. As a consequence you need to handle these details yourself, either in your own code or in some underlying application framework.
At the time of writing, if you are using PHP you are probably using it as an Apache module (if you're not and you want to add to this section please drop me an email). Apache (in the 1.3.x series) forks a child process for each request it deals with concurrently.
What this means is that if you have a maximum of 150 Apache child processes you might conceivably have 150 connections to your PG server (or more if a page request opens multiple connections). If you can't support this many concurrent connections, you need to handle this gracefully in your code.
Every time you make a connection to the database, it takes a small but significant amount of time to start up another backend, negotiate and authenticate the connection. With a simple query on a small PHP page this can be a sizable percentage of your execution time.
PHP offers a facility to maintain a connection between calls with the pg_pconnect() function. This function will re-use a previous connection if one is available. Note that this connection is per apache process rather than shared between them all. So - the total number of connections to your database will tend to approach the number of current apache child processes - remember to configure MaxSpareServers in Apache's httpd.conf.
If you use AOLserver instead of Apache, it's threaded model should allow better pooling of connections. Having said that, I don't think PHP will work with AOLserver because PHP isn't threaded.
Finally, there are some things it isn't suitable to do in PHP. Long-lived queries (a quarterly report say) will time out either in PHP or in the user's web browser before the results are available. Set up a separate client program to handle these tasks and save its result to a suitable temporary file. You will need a status page for users to check or you can email them a URL when the results are ready.