Problems with DBD:Pg

Hi

I am in the process of migrating a web application from a small linux server
(Fedora 2, AMD processor), to a new larger box running RHEL 4, AMD64.

The version of postgres (8.1.3), DBD::Pg(1.47) and everything else (data and
application) is the same.

However, on the new server, two reports are consistently showing the following
error

ERROR: prepared statement "dbdpg_1" does not exist

The two reports have multiple cursors (3 levels) and have never had a problem
before. I have error checked the cost, and there are no errors prior to
calling 'execute', but the execute fails with the above error.

A test version of one report runs without error from the command, but when
invoked via ModPerl/Apache we get the above error.

Has anyone seen problems before with Prepared statements failing, and know of
a solution?

Thanx

Simon
--
Simon Windsor
Eml: simon.windsor@cornfield.org.uk
Tel: 01454 617689
Mob: 07960 321599

Re: Problems with DBD:Pg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> ERROR: prepared statement "dbdpg_1" does not exist
>
> The two reports have multiple cursors (3 levels) and have never had a problem
> before. I have error checked the cost, and there are no errors prior to
> calling 'execute', but the execute fails with the above error.
>
> A test version of one report runs without error from the command, but when
> invoked via ModPerl/Apache we get the above error.

That last part is certainly suspicious. Are you running anything else, such
as Class::DBI? Or calling fork() anywhere? Are you sure the DBI->connect call is
being made after the Apache children are spawned? You can probably solve the problem
in the short term by turning off server-side prepares, by issuing

$dbh->{pg_server_prepare} = 0;

at the top of your script. Without seeing more of your script, it's hard to
tell too much more, but the basic problem is that some process created a prepared
statement named "dbdpg_1" and some other process could not find it later, as it
has been removed, proabbly by a statement handle going out of scope. Hence, the
strong suspicion of a fork. You can probably bump the trace level up and search
for "dbdpg_1" to see where and when it is being deallocated.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200604132038
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B90 6714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFEPu8xvJuQZxSWSsgRAuhWAJ9u7og5ryrii7wo1WcBhSGseefoKACf Rxz+
UM6uL7Ca7iXAQVrRquhxInM=
=AEsU
-----END PGP SIGNATURE-----