Re: PEAR DB seems to block 2nd connection from same browser (or CLI execution)

On 9/8/05, Jocke Selin <the.joxor@gmail.com> wrote: > J wrote: > > [..snipped huge post...] > > > > I've added some (quite a lot) of var_dump()s in the code and at no > > > > point is autocommit set to FALSE - it's set to TRUE all the time, > > > > which means that there should not be an "automatic" transaction > > > > wrapped around the code. > > > > if autocommit is set to TRUE all the time, that means that after every > > sql statement, there will be a commit. > > There will be a commit *inside* of PostgreSQL (AFAIK), not manually > executed by PHP (or PEAR DB). > > > if it is set to FALSE that means > > you can do it yourself. also, from justin's comment, there is an > > explicit "begin" command sent to pgsql... that might be a bug, but at > > most it pgsql will complain (if you send another begin) that it is > > already inside a transaction. > > Yup, autocommit is set to TRUE. I added a piece of code that prints > out "Automatic transaction start" in pgsql.php simpleQuery() just > before the code executes: > $result = @pg_exec($this->connection, 'begin;'); > This message never gets outputted - which to me indicates that Pear DB > does *not* do some automagic stuff. > > > > in my experience with pgsql, autocommit is set to TRUE all the time, and > > if I want to do something fancy (like update a couple tables inside a > > transaction and rollback if there is an error) I needed to explicitly > > set autocommit to false. > > We do some of that "fancy" stuff, but never had to set autocommit to > FALSE. AFAIK autocommit = FALSE, is to be used when you don't want a > single query to be autocommitted, such as "DELETE FROM..". > Using autocommit technically means that, internally, PostgreSQL > changes "DELETE FROM..." to "BEGIN; DELETE FROM... ; COMMIT;", If you > add "BEGIN" yourself, PostgreSQL will not commit automatically. To my > knowledge that is. > > Anyway, I don't think that this is a transaction issue. I think this > is an issue with the actual connection, and as the problem doesn't > seem to occurr when native PostgreSQL functions are used, I'm leaning > towards that Pear DB does something "smart" somewhere with the code, > that in turn prevents another connection from accessing the same DB > object.... Just an assumption. > > Humdidum...!? > A few more things to try: - Try adding BEGIN/END to your query manually (just to see if it helps) - Print out all of the info on the connection that PEAR::DB is making and make sure that the parameters are the same a swhat you used with the pgsql_ functions. If it's diferent then perhaps this is the issue. - Look for any table locking code that may be in pgsql.php (I doubt this, but....) -- Justin Patrin