I found a related mention of this issue here:
http://fudforum.org/forum/index.php?t=msg&th=4598&start=0&;
There the fix involved putting using DEALLOCATE when persistent
first, the patch with DEALLOCATE makes prepared statements entirely
useless, as it means you're caching a prepared statement, running it,
then deallocating it immediately afterwards. thats some brilliant php
right there. why didn't they just do a conditional to never prepare on
persistent connections ?
Or as they say at http://www.thedailywtf.com/, "brillant".
before looking into how dbd::pg is internally handling the prepared
statements, are you using some sort of db abstraction layer like rose or
class::dbi. or are you executing directly? if executing directly,
are you creating statement handles on the outset, or are you just
letting dbdpg handle all of that internally?
We have no abstraction layer, just using SQL::Interpolate to help with
SQL generation. (recommended!). We create statement handles if there is
a need, but usually not.
the prepared statement 'handle/name' is private to the session. so two
different connections will each have their own statement handle.
my guess on things to look into:
how is dpd::pg caching the statement handle? are they even doing it?
where is the statment handle being cached, accessed, checked? in
the memory space of the child, or in the shared area?
If "shared" means "what happens in startup.pl", then there's no SQL
being executed there.
Mark
--
http://mark.stosberg.com/
