On Dec 12, 2008, at 9:48 AM, Krawetz, Neal wrote: > On Thu, Dec 11, 2008 at 11:04:12PM -0700, Bob Gobeille wrote: >> What error is returned from the postgres call after the DB connection >> has been reset? You said that the DB call in the php script returns >> no data. If it returns with no data, I would expect an error to be >> set. >> >> Bob > > I just enabled full debugging. > The result is inconsistent. > > When it fails: > > $result = pg_execute($this->_pg_conn,$Prep,$Command); > > Sometimes $result is set, but contains no value. > This causes $rows = pg_fetch_all($result); to fail. > This seems to be the most common death.
When pg_execute fails it returns false. So what you are seeing seems to be correct. If you try to fetch after getting a $result = false, then that is a program error. When pg_execute fails, you should call pg_last_error(). > NOTE: There is no PG error detected from pg_execute. How are you checking? You won't be able to use pg_result_error because you don't have a $result. > Other times (less often) I see: > -------- > SQL failed: SELECT * > FROM uploadtree > INNER JOIN pfile ON pfile_pk = pfile_fk > INNER JOIN mimetype ON pfile.pfile_mimetypefk = > mimetype.mimetype_pk > WHERE uploadtree_pk = 3462 LIMIT 1; > FATAL: 57P01: terminating connection due to administrator command > LOCATION: ProcessInterrupts, postgres.c:2270 > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > -------- > This usually happens with: > @$result = pg_query($this->_pg_conn,$Command); > > > Notice how it dies in "ProcessInterrupts, postgres.c:2270". > All of the problems we have seen so far have been interrupt and signal > issues with -lpg. So if the postmaster terminated the connection, I imagine the correct response is to sleep and retry. Bob _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
