Peter Eisentraut wrote: > Neil Conway wrote: > >>The specific scenario this feature is intended to resolve is >>idle-in-transaction backends holding on to resources while the >>network connection times out; > > > I was under the impression that the specific scenario is > busy-in-transaction backends continuing to produce and send data while > the client has disappeared. Why does the backend ignore network errors > and keep sending data?
The scenario I need to deal with is this: There are multiple nodes, network-separated, participating in a cluster. One node is selected to talk to a particular postgresql instance (call this node A). A starts a transaction and grabs some locks in the course of that transaction. Then A falls off the network before committing because of a hardware or network failure. A's connection might be completely idle when this happens. The cluster liveness machinery notices that A is dead and selects a new node to talk to postgresql (call this node B). B resumes the work that A was doing prior to failure. B has to wait for any locks held by A to be released before it can make any progress. Without some sort of tunable timeout, it could take a very long time (2+ hours by default on Linux) before A's connection finally times out and releases the locks. -O ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
