FAQ
Hi list!

I was testing a high-availability cluster of postgres databases when I
stumbled on a problem: a call to execute blocks and never returns
hence making the application hang forever instead of failing.

That was the short story. The long one is as follows: I wrote a script
that inserts into a remote postgres database in an infinite loop. The
script connects to the remote database over a tcp socket. At some
point, I block traffic to the postgres database by setting an iptable
reject rule on the database server. At that point, the script freezes.
I turned on trace in DBI and saw that the script freezes due to a
blocking execute call. I was expecting execute to emit an error when
the tcp socket gets closed by the reject iptable rules, but it does
not. So I tried with an iptable drop rule, which is just a way of
simulating someone plugging out the ethernet cable to the database
server, but the reaction was the same: execute blocks forever.

Is this a normal behavior for execute?
Is there any built-in way to set a timeout on execute, or to force it
to detect connection errors at the tcp level? (I could use the
eval/alarm trick in the application, but it feels rather unsafe)

Thanks by advance!
/Erwan Lemonnier

Search Discussions

  • Greg Sabino Mullane at Dec 17, 2009 at 9:48 pm

    Is this a normal behavior for execute?
    Is there any built-in way to set a timeout on execute, or to force it
    to detect connection errors at the tcp level? (I could use the
    eval/alarm trick in the application, but it feels rather unsafe)
    I'd feel completely safe about eval/alarm, as long as it works reliably
    on your platform (and it does unless you have something really obscure
    or ornery). I don't think there is anything you can do to set it to
    timeout other than an alarm, nor do I think there is a way to detect
    things at a lower level (as far as DBD::Pg / DBI / libpq / perl is
    concerned, the traffic is simply held up and will arrive someday).

    You might also ask on #postgresql on freenode, there are some
    smart people there who can give a better answer than I can.

    - --
    Greg Sabino Mullane greg@turnstep.com
    PGP Key: 0x14964AC8 200912171647
    http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbd-pg @
categoriesperl
postedNov 11, '09 at 9:27a
activeDec 17, '09 at 9:48p
posts2
users2
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase