[horde] horde 3.0.5, postgresql session handler fails

[Chris Stromsoe]

On Sat, 8 Oct 2005, Chuck Hagenbuch wrote:

> If there's no new read() call there, that's probably a bug in PHP - 
> getCleanSession() triggers a complete re-set of the session handler. 
> What PHP version do you have?

I've tested with 4.4.0 and 5.0.5.

When is the new read() supposed to happen?  After the call to write() 
fails?  Right now I'm seeing:  read(), do some stuff, getCleanSession(), 
do some stuff, write().  Due to other issues I haven't solved, I'm getting 
stuck there.

>> Because the update query includes the COMMIT, I'm pretty sure that 
>> pg_affected_rows() will return the result of the COMMIT not the result 
>> of the UPDATE, which means that the test for pg_affected_rows() == 0 
>> will always be true.  Testing to see if the UPDATE was succesful should 
>> probably be testing for pg_affected_rows() == 1.
>
> If you can test this and post a patch on bugs.horde.org it'd be greatly 
> appreciated.

I have a patch, but I'm running into some other issues that are preventing 
me from testing it completely.  Returning false from the write() handler 
is resulting in php (both 4.4.0 and 5.0.5) hanging the attached apache 
process (server-status reports the pid as "sending reply"; gdb backtraces 
are showing up variously in free(), malloc(), realloc() in libc called out 
of various points in libphp and haven't been terribly helpful so far).

Anyway, the patch is attached to bug #2749.  It also includes some 
whitespace cleanup to make lines not wrap on an 80-column terminal, and 
removes some bogus calls to pg_free_result() that were inside of if 
(!$result) {} blocks.


-Chris