AW: AW: timeout on lock feature
Zeugswetter Andreas SB <zeugswettera@wien.spardat.at>
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Henryk Szal <szal@doctorq.com.pl>, pgsql-hackers@postgresql.org
Date: 2001-04-17T15:20:25Z
Lists: pgsql-hackers
> > Bruce Momjian <pgman@candle.pha.pa.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