Re: AW: timeout on lock feature

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, Henryk Szal <szal(at)doctorq(dot)com(dot)pl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: timeout on lock feature
Date: 2001-04-17 15:16:54
Message-ID: 23768.987520614@sss.pgh.pa.us
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:
> 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-04-17 15:20:25 AW: AW: timeout on lock feature
Previous Message Tom Lane 2001-04-17 15:01:23 Re: Re: No printable 7.1 docs?