Re: Persistent connections and transactions

On Thu, Jan 25, 2001 at 04:04:24PM -0300, Martin A. Marques wrote: [ . . . ] > Of course. But the persistent connection are not working as the manuals say > they should work. It appears this riddle has been solved: From a post by Adam Lang on pgsql-php on Dec 8: <start quote> Well, there's a problem with PHP's [mis]documentation. First of all, it counts open DB connections not on per-webserver, but on per-process/thread basis. The default PHP config file has the limits of persistent and non-persistent connections set to -1 (no limit)... Setting it to some (supposedly) reasonable value (like, 50) accomplishes nothing: you should multiply 50 by the number of webserver processes/threads. There can be lots of them... :[ And then there comes PHP's "logic": if I can just open the new connection, why bother reusing the old one? And thus Postgres backends start multiplying like rabbits, eventually reaching the limit... :[ You should set a reasonable limit on number of open persistent connections (like 1, maybe 2 or 3), only then PHP will actually reuse them. My webserver now works with such setup and there are no more problems with pg_pconnect(). <end quote> [ . . . ] > > Hmm. Say the Apache child is idle (under which cirumstances exactly does > > it consider itself 'idle'?), receives a request for a page which > > executes a query (because it contains php code that does). This takes a > > while. In the meantime, while the SQL server is chugging away running > > the query, will the Apache child not accept further http requests? How > > does the Apache child know that it is waiting for the query to complete? > > This is what I don't know about the mechanism. > > That has nothing to do with apache. If the SQL statments are well > implemented, the second query wouldn't see any of the changes that the first > query executed until the work is commited, and it shouldn't be able to modify > the rows with which the first query is updating or deleting. > But thats Postgres that doesn't let it, not the apache server, not php. You are assuming that the Postgres backend has accurate information about the client's identity. The "client" for the backend is the Apache child, not the browser. The Postgres backend doesn't know anything about web browsers. So if Apache/PHP allows a 2nd browser to connect to a particular Apache process while it's waiting for a query to complete that would generate information to be sent back to the first browser, then you're in trouble. But I think it would be pretty silly for Apache/PHP to allow that. Regards, Frank