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 A08D1DB9D6 for ; Thu, 17 Nov 2005 17:07:03 -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 26261-06-2 for ; Thu, 17 Nov 2005 21:07:04 +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 20790DB9A7 for ; Thu, 17 Nov 2005 17:06:58 -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 A57BFF0B59 for ; Thu, 17 Nov 2005 21:07:00 +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 jAHLFNlw025202; Thu, 17 Nov 2005 13:15:23 -0800 Message-ID: <437CF055.6020602@modgraph-usa.com> Date: Thu, 17 Nov 2005 13:04: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 To: Michael Fuhr Cc: Pgsql-Performance Subject: Re: Perl DBD and an alarming problem References: <1132136225.5711.4.camel@Panoramix> <437B9DA9.2030806@modgraph-usa.com> <20051117002344.GA55377@winnie.fuhr.org> In-Reply-To: <20051117002344.GA55377@winnie.fuhr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.095 required=5 tests=[AWL=0.095] X-Spam-Score: 0.095 X-Spam-Level: X-Archive-Number: 200511/334 X-Sequence-Number: 15591 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(); >> 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... > > > High-level languages' signal handlers don't always work well with > low-level libraries... > > Is there a reason you're using alarm() in the client instead of > setting statement_timeout on the server? statement_timeout solved the problem, thanks VERY much for the pointer. To answer your question, I use alarm() because all the books and web references said that was how to do it. :-). I've used alarm() with Perl (with a 3rd-party C lib that had a potential infinite loop) very successfully. So thanks for the pointer to statement_timeout. But... 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, and that works. Craig