>> I found a related mention of this issue here:
>> http://fudforum.org/forum/index.php?...=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:g 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:g 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.