Re: Fwd: libpq: indefinite block on poll during network problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Samonenko <shreddingwork(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Fwd: libpq: indefinite block on poll during network problems
Date: 2014-05-30 14:08:52
Message-ID: 2388.1401458932@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dmitry Samonenko <shreddingwork(at)gmail(dot)com> writes:
> So, should I fill a bug report?

[ shrug... ] This is not a bug. It might be a feature request, but
I doubt that it's a feature anybody would be interested in implementing.
Adding timeouts to libpq would mean adding hard-to-test (and therefore
easy-to-break) logic paths, in service of what seems like a very debatable
design decision. It's really the business of the network stack to decide
when a TCP connection has been lost, not libpq. And it's not exactly
clear what recovery action libpq should take if it were to decide the
connection had been lost first.

BTW, you might consider using libpq's nonblock mode to push the waiting
out to the application level, and then you could just decide when you've
waited too long for yourself.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message CS_DBA 2014-05-30 15:35:30 Replication failover on windows
Previous Message Claudio Freire 2014-05-30 13:36:37 Re: Extended Prefetching using Asynchronous IO - proposal and patch