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