-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> Then after adding the column the error changes to:
>
> "DBD::Pg::st execute failed: \
> ERROR: prepared statement "dbdpg_p14158_3" does not exist
> [for Statement "SELECT id, bar, foo from baz ....
Generally, this happens because the statement has been explicitly
deallocated. It does this when the statement handle goes out of scope.
Are you using any sort of forking or shared connections that could cause
this? Another possibility is that the backened is removing that prepared
statement as it knows it is no longer valid. I've not been able to replicate
that on some quick 8.3 testing, however.
Can you tell us what versions of DBI, DBD::Pg, and Postgres you are using?
Can you narow it down to a reproducibale test case? Barring that, you
might try turning on some tracing to see what is going on. Just the SQL
level should at least show you where the prepared statement is getting
created, called, and destroyed. You can send it to a file to not disrupt
your application with something like this:
$dbh->trace('SQL', '/tmp/dbdpg.debug.log');
>One thing throwing me off is that first error says
> execute failed
> not "prepare failed". But, I assume that was really a prepare.
No, it's executing a previously prepared statement, so execute is correct.
> Anyway, if the first error was really from a prepare, shouldn't the
> error be noticed and then remove (or don't store) the "dbdpg_p14158_3"
> key from the cache?
We shouldn't need to: if it fails one time, it should fail the same way in
all subsequent attempts. If I can reproduce the behavior you've seen, however,
there may be a way to have DBD::Pg learn that the prepared statement is no
longer valid.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation
PGP Key: 0x14964AC8 200811211220
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkkm7uAACgkQvJuQZxSWSsgDhQCeLAR9pR1G50jfVTIa+HXbZv7J
wagAn0PiSnbrmhxkzOrcVx7pJjntobC3
=TIn2
-----END PGP SIGNATURE-----
