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.
