Hi,

I've been converting some old CGI scripts for use with mod_perl and Apache::DBI. These scripts access a Postgres database through DBI. I didn't have any trouble until I began writing a new script which in the development phase has generated a few bad SQL commands (my fault, not the problem). This has had the unexpected side effect of preventing *any* older script running in the same process from executing SQL! The error messages for these (perfectly fine) scripts is "current transaction is aborted, commands ignored until end of transaction block," which I'm guessing means that Postgres is assuming I'm in the same transaction as generated the original error, even though it's a completely unrelated script.

So I looked into it and found that Apache::DBI is supposed to have a 'cleanup handler' that automatically does a rollback after a script has been run. Shouldn't this take care of the "ignoring until end of block" thing? I'm fairly new to the 'transactions' concept but I'm guessing that a ROLLBACK or a COMMIT is the same thing as "ending the transaction block", right?

So anyway, I recompiled mod_perl to ensure these kinds of handlers were enabled, restarted the server with $Apache::DBI::DEBUG set to 2, and sure enough, I started getting debug messages about rollbacks after each script finished executing. Problem is.. they stopped, after awhile. Mysteriously, about an hour after restarting, the cleanup handlers either aren't running or aren't printing debug info anymore, and the 'transaction aborted' errors are back. Does anyone know what could cause this, or how I could better diagnose my system?

I'm running Postgres 7.4, Perl 5.8.1, mod_perl 1.29 and Apache 1.3 on Mac OS X Panther; mod_perl is using PerlRun and Apache::StatINC.

Brian



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Reply via email to