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 по дате отправления: