On P, 2005-05-01 at 11:37 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > The problem, as I understand it, is that if you have a long-running
> > query and the client process disappears, the query keeps running and
> > holds whatever resources it may have until it finishes.
>
> There is a trivial solution for this: it's called statement_timeout.
statement timeout does not solve the fundamental problem of server not
seeing when a cleint connection has disappeared.
I had another variant of the same problem - i had 300 client connections
to the same postmaster, postmaster was configured to handle 500
simultaneous connections. Then there was a network outage for a few
minutes, during which clients saw that the postmaster was not there and
closed their conections and tried to make new ones. After the network
came back, only 200 of them were able to reconnect, as the server never
saw them leaving and just kept the 300 zombie connections.
> It might be interesting to think about a transaction_timeout as well,
> to bound the time locks can be held. But none of this has anything
> to do with "high availability" as I understand the term. It looks
> more like a forcing function to make your users fix poorly-written
> client software ;-)
Im my case all ttransactions were implicit one command functon calls
("select * from dbfunc()"), so transaction timeout would not help.
probably the only way for server to detect stale connections would be
sending/receiving some kind of keepalives.
--
Hannu Krosing <hannu@skype.net>
