Re: Perl DBD and an alarming problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux