Re: [PERFORM] Perl DBD and an alarming problem

2005-11-19 Thread Craig A. James
When I set statement_timeout in the config file, it just didn't do anything - it never timed out (PG 8.0.3). ... but did you reload the server after you [changed statement_timeout]? Mystery solved. I have two servers; I was reconfiguring one and restarting the other. Duh. Thanks, Craig

Re: [PERFORM] Perl DBD and an alarming problem

2005-11-17 Thread Michael Fuhr
On Thu, Nov 17, 2005 at 01:04:21PM -0800, Craig A. James wrote: When I set statement_timeout in the config file, it just didn't do anything - it never timed out (PG 8.0.3). I finally found in the documentation that I can do set statement_timeout = xxx from PerlDBI on a per-client basis,

Re: [PERFORM] Perl DBD and an alarming problem

2005-11-17 Thread Michael Fuhr
[Please copy the mailing list on replies.] On Thu, Nov 17, 2005 at 05:38:13PM -0800, Craig A. James wrote: You probably shouldn't set statement_timeout on a global basis anyway The server is a one trick pony so setting a global timeout value is actually appropriate. Beware that

Re: [PERFORM] Perl DBD and an alarming problem

2005-11-16 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am mystified by the behavior of alarm in conjunction with Postgres/perl/DBD. Here is roughly what I'm doing:

Re: [PERFORM] Perl DBD and an alarming problem

2005-11-16 Thread Michael Fuhr
On Wed, Nov 16, 2005 at 12:59:21PM -0800, Craig A. James wrote: eval { local $SIG{ALRM} = sub {die(Timeout);}; $time = gettimeofday; alarm 20; $sth = $dbh-prepare(a query that may take a long time...); $sth-execute(); alarm 0; }; if ($@ $@ =~