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 <
> shreddingwork@
> > 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.
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. |