On Fri, Dec 12, 2008 at 10:05:16AM -0700, Bob Gobeille wrote:
>
> 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().
I had that for one type of query, but not for the other.
I just added that in.
But in both cases, I was already checking if $result was set and setting
an error.
> So if the postmaster terminated the connection, I imagine the correct
> response is to sleep and retry.
In the case of the scheduler, the library call never returns.
I don't have the option to sleep/retry or reset the connection.
-Neal
_______________________________________________
fossology mailing list
[email protected]
http://fossology.org/mailman/listinfo/fossology
