Perl DBD and an alarming problem
| От | Craig A. James |
|---|---|
| Тема | Perl DBD and an alarming problem |
| Дата | |
| Msg-id | 437B9DA9.2030806@modgraph-usa.com обсуждение исходный текст |
| Ответ на | Re: Performance PG 8.0 on dual opteron / 4GB / 3ware (Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>) |
| Ответы |
Re: Perl DBD and an alarming problem
Re: Perl DBD and an alarming problem |
| Список | pgsql-performance |
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->execute();
alarm 0;
};
if ($@ && $@ =~ /Timeout/) {
my $elapsed = gettimeofday - $time;
print "Timed out after $elapsed seconds";
}
Now the mystery: It works, but it hardly matters what time I use for the alarm call, the actual alarm event always
happensat 26 seconds. I can set "alarm 1" or "alarm 20", and it almost always hits right at 26 seconds.
Now if I increase alarm to anything in the range of about 25-60 seconds, the actual alarm arrives somewhere around the
90second mark. It seems as though there are "windows of opportunity" for the alarm, and it is ignored until those
"windows"arrive.
Anyone have a clue what's going on and/or how I can fix it?
A secondary question: It appears that $sth->cancel() is not implemented in the Pg DBD module. Is that true?
Thanks,
Craig
В списке pgsql-performance по дате отправления: