RE: Fundamental change of locking behavior in 7.1

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Zeugswetter Andreas SB" <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Fundamental change of locking behavior in 7.1
Date: 2000-11-17 22:36:49
Message-ID: EKEJJICOHDIEMGPNIFIJAECFCOAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Zeugswetter Andreas SB
>
> 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
>

In PostgreSQL,'lock table' acquires a AccessExclusiveLock by default.
IMHO ExclusiveLock is sufficient for ordinary purpose. It doesn't conflict
with AccessShareLock. Oracle doesn't have AccessExclusive(Share)Lock
and I've been suspicious why users could acquire the lock explicitly.

Comments ?

Regards.
Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-11-17 22:43:44 Re: Coping with 'C' vs 'newC' function language names
Previous Message Tom Lane 2000-11-17 22:30:13 Re: [rfc] new CREATE FUNCTION (and more)