AW: AW: timeout on lock feature
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: AW: timeout on lock feature |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA68796336828C@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: AW: timeout on lock feature
Re: AW: AW: timeout on lock feature |
Список | 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
В списке pgsql-hackers по дате отправления: