AW: AW: timeout on lock feature

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Henryk Szal <szal(at)doctorq(dot)com(dot)pl>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: timeout on lock feature
Date: 2001-04-17 15:20:25
Message-ID: 11C1E6749A55D411A9670001FA68796336828C@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > 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.
>
> I envisioned:
>
> SET TIMEOUT TO 10;
> UPDATE tab SET col = 3;
> RESET TIMEOUT
>
> Can't we get that work work properly? Let the timeout only apply to the
> 'tab' table and none of the others. Can't we exclude system tables from
> being affected by the timeout?

Why exactly would you be willing to wait longer for an implicit system table lock?
If this was the case you should also be willing to wait for the row lock, no ?
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).

> Requiring a LOCK statement that matches
> the UPDATE/DELETE and wrapping the whole thing in a transaction seems
> needlessly complex to me.

Agreed.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-04-17 15:29:30 AW: AW: timeout on lock feature
Previous Message Tom Lane 2001-04-17 15:16:54 Re: AW: timeout on lock feature