Thread: AW: AW: timeout on lock feature

> > Added to TODO:
> >     * Add SET parameter to timeout if waiting for lock too long
> 
> I repeat my strong objection to any global (ie, affecting all locks)
> timeout.  Such a "feature" will have unpleasant consequences.

Except that other people like myself, see those consequences 
as a pleasant thing :-) And we are talking about something that has to be
requested by the client explicitly (at least in a default installation).

It simply does make sense for an interactive client to not block 
more than ~ 30 seconds.

Andreas

> > The timeout will be useful to let the client or user decide
> > on an alternate course of action other that killing his
> > application (without the need for timers or threads in the
> > client program).
> 
> This assumes (without evidence) that the client has a good
> idea of what the timeout limit ought to be. I think this "feature"
> has no real use other than encouraging application programmers to
> shoot themselves in the foot. I see no reason that we should make
> it easy to misdesign applications.

AFAIR, Big Boys have this feature. If its implementation is safe,
ie will not affect applications not using it, why do not implement it?

Vadim

Hi,

for 10 years i develop DB application using 'timeout on lock' feature
(Informix,Ingres,AdabasD,RDB,...).
I think about migrate with this application to postgresql, and with this
feature i don't need to modify my ready to run code specially for
postgresql. This feature guard me against blocking terminals, because long
query
initialized by operator (or administrator).

"Mikheev, Vadim" wrote in message
<8F4C99C66D04D4118F580090272A7A234D33AC@sectorbase1.sectorbase.com>...
>> > The timeout will be useful to let the client or user decide
>> > on an alternate course of action other that killing his
>> > application (without the need for timers or threads in the
>> > client program).
>>
>> This assumes (without evidence) that the client has a good
>> idea of what the timeout limit ought to be. I think this "feature"
>> has no real use other than encouraging application programmers to
>> shoot themselves in the foot. I see no reason that we should make
>> it easy to misdesign applications.
>
>AFAIR, Big Boys have this feature. If its implementation is safe,
>ie will not affect applications not using it, why do not implement it?
>
>Vadim
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://www.postgresql.org/search.mpl

OK, we have it on the TODO list, so it will hopefully be added soon, in
some fashion.  I like the SET or the BEGIN TIMEOUT options.

> Hi,
> 
> for 10 years i develop DB application using 'timeout on lock' feature
> (Informix,Ingres,AdabasD,RDB,...).
> I think about migrate with this application to postgresql, and with this
> feature i don't need to modify my ready to run code specially for
> postgresql. This feature guard me against blocking terminals, because long
> query
> initialized by operator (or administrator).
> 
> "Mikheev, Vadim" wrote in message
> <8F4C99C66D04D4118F580090272A7A234D33AC@sectorbase1.sectorbase.com>...
> >> > The timeout will be useful to let the client or user decide
> >> > on an alternate course of action other that killing his
> >> > application (without the need for timers or threads in the
> >> > client program).
> >>
> >> This assumes (without evidence) that the client has a good
> >> idea of what the timeout limit ought to be. I think this "feature"
> >> has no real use other than encouraging application programmers to
> >> shoot themselves in the foot. I see no reason that we should make
> >> it easy to misdesign applications.
> >
> >AFAIR, Big Boys have this feature. If its implementation is safe,
> >ie will not affect applications not using it, why do not implement it?
> >
> >Vadim
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 6: Have you searched our list archives?
> >
> >http://www.postgresql.org/search.mpl
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026