Re: Feature freeze date for 8.1

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Feature freeze date for 8.1
Дата
Msg-id 4275E983.7050201@opencloud.com
обсуждение исходный текст
Ответ на Re: Feature freeze date for 8.1  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Feature freeze date for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Brent Verner
Дата:
Сообщение: Re: custom guc vars
Следующее
От:
Дата:
Сообщение: Re: Feature freeze date for 8.1