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
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 |