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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
