Thread: libpq - prevent automatic reconnect

libpq will automatically reconnect if the connection is dropped.

 auto con = PQconnectdb("info");  while (true) {   PQclear(PQexec(con, "SELECT * FROM foo LIMIT 1"));   std::this_thread::sleep_for(std::chrono::seconds(1));   std::cout << "here " << i++ << std::endl; }

$ sudo ifconfig eth0 down

output stops

$ sudo ifconfig eht0 up

output resumes

is there a way to disable this behaviour?

---

View this message in context: libpq - prevent automatic reconnect
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

icholy <ilia.choly@gmail.com> writes:
> libpq will automatically reconnect if the connection is dropped.

No it won't.  You'd have to do a PQreset() to make that happen.

>   auto con = PQconnectdb("info");    while (true) {    PQclear(PQexec(con,
> "SELECT * FROM foo LIMIT 1"));
> std::this_thread::sleep_for(std::chrono::seconds(1));    std::cout << "here
> " << i++ << std::endl;  }

This test case doesn't prove much of anything, since it's not examining
the PGresult to see if it was OK or an error.

> $ sudo ifconfig eth0 down
> output stops

I suspect this action isn't dropping the TCP connection.  It's only
equivalent to a momentary glitch in your network connectivity --- and
you'd be very unhappy if that caused TCP connections to go down, because
networks have glitches all the time.  Generally, the operating system
tries hard to prevent applications from even knowing that a glitch
happened.  (Connections will time out eventually if connectivity doesn't
come back, but typically such timeouts are many minutes.  Possibly
whatever your real complaint is could be addressed by twiddling the TCP
timeout parameters for the socket.)

            regards, tom lane

On Thu, Dec 6, 2012 at 5:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I suspect this action isn't dropping the TCP connection.  It's only
> equivalent to a momentary glitch in your network connectivity --- and
> you'd be very unhappy if that caused TCP connections to go down, because
> networks have glitches all the time.  Generally, the operating system
> tries hard to prevent applications from even knowing that a glitch
> happened.  (Connections will time out eventually if connectivity doesn't
> come back, but typically such timeouts are many minutes.  Possibly
> whatever your real complaint is could be addressed by twiddling the TCP
> timeout parameters for the socket.)

Yep. For a better test, try taking the interface down for a good while
(several minutes), or actually shut down the Postgres server at the
other end.

ChrisA

Chris Angelico wrote:
> On Thu, Dec 6, 2012 at 5:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I suspect this action isn't dropping the TCP connection.  It's only
>> equivalent to a momentary glitch in your network connectivity --- and
>> you'd be very unhappy if that caused TCP connections to go down, because
>> networks have glitches all the time.  Generally, the operating system
>> tries hard to prevent applications from even knowing that a glitch
>> happened.  (Connections will time out eventually if connectivity doesn't
>> come back, but typically such timeouts are many minutes.  Possibly
>> whatever your real complaint is could be addressed by twiddling the TCP
>> timeout parameters for the socket.)
>
> Yep. For a better test, try taking the interface down for a good while
> (several minutes), or actually shut down the Postgres server at the
> other end.

I find PostgreSQL connections, particularly with listen/notify set up,
to be fairly sensitive to disconnection. This is particularly the case
with apps written using either Delphi or Lazarus, where a session is
kept live for an extended period rather than simply being used to
transfer a query and resultset.

This isn't a recent thing, and I'm definitely not saying that it's a
Postgres issue. I've tried forcing random connection drops at the
application level in the past and have never been able to characterise
the problem.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]