At 9:10 AM -0700 5/29/2000, Jeffrey W. Baker wrote:
>On Mon, 29 May 2000, Michael Blakeley wrote:
>
>> Patch for Apache::Session::Store::Postgres, from
>> Apache-Session-1.51.tar.gz, to resolve problems with
>>
>> >prepare_cached(SELECT a_session FROM sessions WHERE id = ? FOR
>> >UPDATE) statement handle DBI::st=HASH(0x369a2c) is still active
>>
>> after a transient error. The solution is to call sth->finish()
>> whether the SELECT was successful or not.
>>
>> diff Store/Postgres.pm.orig Store/Postgres.pm
>> 78a79,81
>> > # success or failure, don't leave FOR UPDATE lying around
>> > $self->{materialize_sth}->finish;
>> >
>> 83,84d85
>> < $self->{materialize_sth}->finish;
>> <
>
>Hrmm, I'm not really an expert here. If I do a SELECT ... FOR UPDATE on a
>row that doesn't exist, shouldn't that just do nothing?
I'm no expert either - but I believe that the problem is the
"unfinished" sth hanging around in DBI or DBD::Pg, rather than any
results or lack thereof. Note that the error comes from
DBI::prepare_cached(), not from the postgres backend. One _could_
regard this as a DBD::Pg bug, if it's not present in other DBD
modules... but what's wrong with the fix above?
According to perldoc DBD::Pg, the prepare/execute thing is fairly
pointless in Postgres anyway. PG doesn't know prepared statements
from /dev/null, so you might as well just selectall_arrayref every
time. I've done some benchmarks that show a very slight improvement
in some cases (possibly due to state maintained by DBD::Pg), but it's
less than 10%.
>To squash this warning, we could just as easily use the allow_active flag
>in the prepare method.
True, but the above seems cleaner to me. Isn't dying and leaving
unfinished statement handles a bit untidy, like leaving unclosed
database handles, or unclosed file handles? It's a potential memory
leak as well, isn't it?
It's not a warning, BTW - for my Apache::Session application, it's
fatal. I've had to patch all previous versions of Apache::Session in
a similar way (somewhere you may have an older email from me on this
subject). The fix originally came from someone else, but I can't find
my notes at the moment to give proper credit.
-- Mike
