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
[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 st
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,
Thanks for the info on alarm and timeouts, this was a big help. One further
comment:
Michael Fuhr 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();
ala
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 ($@ &&
-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:
> A
I am mystified by the behavior of "alarm" in conjunction with
Postgres/perl/DBD. Here is roughly what I'm doing:
eval {
local $SIG{ALRM} = sub {die("Timeout");};
$time = gettimeofday;
alarm 20;
$sth = $dbh->prepare("a query that may take a long time...");
$sth->execut
