X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 90BAFD6D50 for ; Wed, 16 Nov 2005 17:01:56 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 45249-07 for ; Wed, 16 Nov 2005 21:01:57 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr2.postgresql.org (svr2.postgresql.org [65.19.161.25]) by svr1.postgresql.org (Postfix) with ESMTP id 0CFFCD6D16 for ; Wed, 16 Nov 2005 17:01:53 -0400 (AST) Received: from moonunit2.moonview.localnet (wsip-68-15-5-150.sd.sd.cox.net [68.15.5.150]) by svr2.postgresql.org (Postfix) with ESMTP id 858EDF0B58 for ; Wed, 16 Nov 2005 21:01:55 +0000 (GMT) Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3]) by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id jAGLADiV015144 for ; Wed, 16 Nov 2005 13:10:13 -0800 Message-ID: <437B9DA9.2030806@modgraph-usa.com> Date: Wed, 16 Nov 2005 12:59:21 -0800 From: "Craig A. James" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: Pgsql-Performance Subject: Perl DBD and an alarming problem References: <1132136225.5711.4.camel@Panoramix> In-Reply-To: <1132136225.5711.4.camel@Panoramix> Content-Type: text/plain; charset=ISO-8859-13; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.189 required=5 tests=[MISSING_HEADERS=0.189] X-Spam-Score: 0.189 X-Spam-Level: X-Archive-Number: 200511/300 X-Sequence-Number: 15557 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 happens at 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 90 second 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