On Friday, May 30, 2014, David G Johnston <
david.g.johnston@gmail.com> wrote:
Tom Lane-2 wrote
> 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.
I'm troubled with possible 'imperfection' of very simple, yet core feature - PQexec, which can lead to blocked applications. You believe that the problem is caused by client design flaw. Okay, fine. Is it possible to mark this potential problem with warning in official documentation?
Though this then begs the question: if the connection comes back up what
happens in the client?
Depends on the state of the server. If problem was purely network related - TCP retransmit eventually
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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
