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

From: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Fwd: libpq: indefinite block on poll during network problems
Date: 2014-05-30 19:54:21
Message-ID: 1401479661267-5805605.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane-2 wrote
> Dmitry Samonenko &lt;

> shreddingwork@

> &gt; writes:
>> Yeah, that will work. Looks simple to implement in the client. Question
>> is:
>> why don't you think it should be a part of the libpq's API? It's a must
>> have feature in high availability environments where only several minutes
>> of Out of Service per year are tolerable.
>
> That argument seems nonsensical from here. If you need HA then you should
> be using network service monitoring tools, not relying on some random
> libpq client to decide that its connection has been lost.

Though this then begs the question: if the connection comes back up what
happens in the client? If the client is still stuck then I'd say that is
possibly our problem to address - but if the client resumes then expecting
and resolving the issue at a higher level seems to make sensible policy.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/libpq-indefinite-block-on-poll-during-network-problems-tp5805061p5805605.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2014-05-30 20:31:57 Re: [HACKERS] unable to build postgres-9.4 in os x 10.9 with python
Previous Message Chris Hanks 2014-05-30 19:05:14 Re: row_to_json on a subset of columns.