Re: AW: timeout on lock feature
| От | Tom Lane |
|---|---|
| Тема | Re: AW: timeout on lock feature |
| Дата | |
| Msg-id | 23768.987520614@sss.pgh.pa.us обсуждение |
| Ответ на | AW: timeout on lock feature (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
| Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
As Henryk has implemented it, it WON'T only apply to the 'tab' table;
it'll affect all locks grabbed anywhere, including those that the system
locks internally. That scares the heck out of me, Andreas' objections
notwithstanding.
> Can't we exclude system tables from being affected by the timeout?
How will you do that? The lock manager makes a point of not knowing the
semantics associated with any particular lock tag. It's even less
likely to know the difference between a "system" grab and a "user" grab
on what might be the very same lock (consider an "UPDATE pg_class"
command).
> Requiring a LOCK statement that matches
> the UPDATE/DELETE and wrapping the whole thing in a transaction seems
> needlessly complex to me.
As opposed to your three-step proposal above? That doesn't look
very much simpler to me...
regards, tom lane
В списке pgsql-hackers по дате отправления: