[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Feature freeze date for 8.1
From:       Oliver Jowett <oliver () opencloud ! com>
Date:       2005-05-02 8:49:07
Message-ID: 4275E983.7050201 () opencloud ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]