> > Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
