AW: AW: timeout on lock feature

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Henryk Szal <szal(at)doctorq(dot)com(dot)pl>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: timeout on lock feature
Date: 2001-04-17 15:29:30
Message-ID: 11C1E6749A55D411A9670001FA68796336828D@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > 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.

What exactly scares you ? Surely the deadlock resolution should
handle the above decision to ABORT in the same way it currently does.
If not we have something to fix, no?

Of course this might rather be something to consider for 7.2 and not 7.1.1.

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-04-17 15:30:13 AW: AW: timeout on lock feature
Previous Message Zeugswetter Andreas SB 2001-04-17 15:20:25 AW: AW: timeout on lock feature