| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Fundamental change of locking behavior in 7.1 |
| Date: | 2000-11-17 12:15:32 |
| Message-ID: | 11C1E6749A55D411A9670001FA687963368125@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Since I see, that Tom has implemented the "keep a AccessShareLock lock until
transaction end" philisophy I would like to state a protest.
This is a fundamental change in behavior and I would like to see
a vote on this.
The one example we already know is:
session1 session2
begin work; begin work;
select * from tenk1 limit 1;
select * from tenk1 limit 1;
lock table tenk1; --now waits (why should it ?)
lock table tenk1; -- NOTICE: Deadlock detected --> ABORT
I think this is not acceptable in committed read isolation. The AccessShareLock
needs to be released after each statement finishes.
Thank you
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2000-11-17 13:47:49 | Re: Failure to recognise new database |
| Previous Message | Philip Warner | 2000-11-17 10:43:28 | Re: AW: Coping with 'C' vs 'newC' function language namesh |