aaron-I think this may be more of a Maypole design issue than a mod_perl issue -- although there may also be a bit of an application design issue on your part ( which some of your wording suggests ) , and there may be a dbd::pg issue as well.
my input: 1: potential issue in your application:you should be using a startup.pl file to preload the maypole files and your appplication files. that will compile everything on startup. i'm assuming you're not doing that already , because of some wording in your text -- you should be trying to compile everything into apache yourself, not worrying about virtualhosts or apachemain sections.
2: potential issue with maypole / apache your setup might be preparing the statements before the fork .maybe you're using apache::dbi and doing an outright connect, not a connect on init ? or using a global db connection? make sure that you don't connect at all, or do a forceful disconnect on your db handles before you fork, so each apache child has a fresh db connection for itself. newer versions of apache::dbi should do this already, but it doesn't hurt to force it to disconnect ( disconnect is overloaded, so $dbh- >disconnect doesn't work, you need to DBI::Whatever::disconnect ( $dbh ) )
3: potential issue with dbd::pg / dbiin 1.48(?) there was some issue with the way that prepared statments were cached. i think the fix was to simply include the PID of the process that created them. i'm a bit confused on the whole topic, because there was a lot of blame going back and forth about a year ago -- dbi said it was the dbd problem, dbd said it was an apache::dbi problem, apache::dbi said it was a user config problem. eventually most things got patched to circumvent the situation from happening.
make sure you're up to date i hope that helps. On May 31, 2007, at 11:32 AM, Aaron Trevena wrote:
Hello you wonderful helpful people :) I've just moved a web application (maypole/c::dbi) from one development server to another, previously the code worked fine but now I get : 'prepared statement "dbdpg_1" does not exist' on every (prepared) query to the database. There only are two differences: the version of postgres and the apache configuration - other than that the dependancies all match. On the problem server the perl content handler is in a location outside of a virtual host, in the working server is in a location inside a virtual host. The problem server also has postgres 8.1 and the working server has postgres 7.4 - this shouldn't make any difference (although 8.1 is backwards incompatible enough to have caused problems previously with querys no longer being valid *sigh*). So my question is - will having a content handler in a location directive outside of virtual host cause it to be compiled before forking, and after forking if inside a virtual host? As pre-forking seems to be blamed in the few examples I could find with google.
// Jonathan Vanasco| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| SyndiClick.com| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.