Re: Feature freeze date for 8.1

On Sun, 01 May 2005 11:37:47 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Peter Eisentraut <peter_e(at)gmx(dot)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 is not a solution if many processes are
waiting the resource. statement_timeout is providing a
escape mechanism. Imagine tens of processes are waiting,
statement_timeout refuses them but this processes must do
their works.

>If the concern is that a process may block other processes
>for a long
>time, what does it matter whether the client is still
>connected or not?
>It's the long-running command in itself that is the
>problem. So you
>limit the time the command can run.
>
>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 ;-)

Listen Tom, write a client software that releases the
resources / locks that was hold before client power is down
or client connection was lost.

Do we must suggest this solution to ppl that wants to use
PostgreSQL or do we must implement a pinging mechanism to
check whether client is dead or live ?

Best Regards

Adnan DURSUN
ASRIN Bilişim Hiz.Ltd.
Ankara / TURKEY