Fundamental change of locking behavior in 7.1

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: Raw Message | Whole Thread | 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

Responses

Browse pgsql-hackers by date

  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